Jump to content

  • Log In with Google      Sign In   
  • Create Account

Josh Petrie

Member Since 11 Jun 2003
Offline Last Active Private

#5315578 Team makeup

Posted by on 17 October 2016 - 12:55 PM

That doesn't seem too bad. I generally think that ten people is about the upper-limit of one's ability to effective directly manage a group, so to that end having one person serve as the "art director" and primarily oversee and coordinate the artists in various ways seems reasonable. Having one person focused on business and legal issues is also not entirely uncommon.


I would expect at least one more producer/management role to both interface with the art manager and to manage the "other" development roles remaining (programmers, etc). So three management positions seems totally fine. Four, where the extra is another production role, seems like it might create a bit of overlap but it isn't egregious. Especially if these production roles are also contributing in other ways.

#5315561 Team makeup

Posted by on 17 October 2016 - 11:27 AM

I don't really think percentages are very informative here. What are the actual numbers? What constitutes "management" here? I can totally see a valid scenario where the role of the "management" types is to wrangle and serve as a production role for the high volume of artists, to make sure nobody is duplicating work and everybody is producing art that is actually relevant what will ship in the game.

#5315207 UML diagrams for video games

Posted by on 14 October 2016 - 09:58 AM

Microsoft is a huge company with many different teams. Some might use UML to varying degrees. None of the (game development) teams I worked with while I was at Microsoft ever did anything with it.


Similarly, I have been in this industry for over a decade and never seen anybody use formal UML for anything. Sometimes you see some rough, UML-like box-and-arrow sketches on a whiteboard, but they are crude and transient.


As for your actual original question: you'd build the UML diagrams for the engine the same way you'd build them for any other piece of software. A game engine is just software, at the end of the day, and there's not really a whole lot special about it. If you are unfamiliar with the process for turning an abstract design into a UML diagram in the form appropriate for your class, you may want to review your course notes.

#5315205 Why is visual studio giving me a bunch of false errors?

Posted by on 14 October 2016 - 09:54 AM

Oh.. I thought include guards protected against circular dependencies fully.


Not at all, really. Include guards prevent errors related to redefinition or redeclaration of the contents of the included files. Since circular includes also result in redefinition errors, they do protect against that aspect of the problem, but that's not the whole story. They also help protect against infinitely-nested recursive includes, although the preprocessor usually also has an include-depth limit as well.


The issue you're seeing with circular includes, the one include guards cannot protect against, is that you're not ending up redefining anything from your headers, you're ending up with a preprocessed TU that uses things before they are defined. Application.h includes GameState.h which includes Application.h. But header files aren't seen by the compiler. The preprocessed results of .cpp files are. Say some .cpp file #includes Application.h first. The content of Application.h is pasted above the text of that .cpp file, essentially. Then the #include for GameState.h from Application.h is processed and the content of GameState.h is pasted above Application.h. Then the include for Application.h is processed but your include guard causes the preprocessor to early-out. Now you have the file contents in this order, top to bottom:


  • GameState.h
  • Application.h
  • Whatever.cpp


Since you wrote GameState.h such that it required the full definition of Application, the C++ compiler will see that code, not have any idea what Application is (since it's not declared until halfway down the file), and give you an error. That's why you can fix the issue with a forward-declaration.

#5315037 Why is visual studio giving me a bunch of false errors?

Posted by on 13 October 2016 - 01:47 PM

The way you posted those errors suggests to me you copied them from the "Error Browser" in Visual Studio. Do yourself a favor and close that window and never open it again. Find the option in the settings to disable it's automatic appearance.


The Error Browser insists, in C++, on sorting errors by some very unusual metric that makes no sense. It is effectively a random arrangement of your compiler errors. This is very problematic in C++ because often the first (or earlier) errors are effectively causing the later errors by putting the compiler into a bad state where it doesn't correctly parse your code. This can result in apparent "nonsense" errors.


Look for errors in the output window, that way you can find the first one (oldest, closest to the top of the list) and fix that one first. I also agree with Rattrap's assessment.

#5315013 Why is visual studio giving me a bunch of false errors?

Posted by on 13 October 2016 - 10:56 AM

It's not a intellisense error, it's when I build it only.


You can generally trust the compiler that runs when you build to be accurate (as opposed to the compiler that runs -- yes, it is a different compiler -- to generate Intellisense). So as far as that compiler is seeing, you're calling the function with one parameter.


Possible explanations include not calling the function you think you are calling, and sending old source code (or source code you don't think you're sending) to the compiler. I'd vote the latter given your other notes about Intellisense and go-to-definition not working right. You likely have a messed up build environment for your project. 

#5314993 Why is visual studio giving me a bunch of false errors?

Posted by on 13 October 2016 - 09:28 AM

Are these errors when you build, or errors produced by the Intellisense engine and displayed in the summary window or as red squiggles under the code before you build?

#5314573 separating Volunteer Experience from Prfessional Experience?

Posted by on 10 October 2016 - 03:07 PM

People can react wildly differently to relatively innocuous presentation decisions like this, oddly enough. I've seen people wanting to toss an entire resume simply because the candidate had "the gall" to list a hobby project under the "Experience" header.



My personal preference would be to simply list everything in one section and classify each thing that is a hobby/indie/whatever project as such rather than split them out. But that's me. So I'd say by way of advice that you should make the decision based on how the results look. If splitting them would leave an unbalanced "non-professional experience" section with way fewer items, for example, I don't feel like it benefits you in any way. If you have a relatively even split, sure. It's probably not a decision that is worth worrying about too much, as long as you aren't trying pass off hobby work as professional, somebody-paid-you-for-this work you'll probably be fine, but you're always going to run the risk of people with their own weird personal views on how a resume "must be" structured.

#5313072 Cleanup and return from main in case of a crash or just display error message...

Posted by on 28 September 2016 - 12:12 PM

I use both. I pick the one that I feel is most appropriate and useful for the specific context. Because throwing exceptions in C++ across DLL boundaries can be problematic due to C++'s lack of an ABI, I'd probably confine exceptions to the DLL itself and use error codes or some other kind of notification to report errors across the boundary if I were writing something generic where I couldn't guarantee for eternity that the same runtimes would be used.



Return error codes or similar result objects is generally a simpler solution that is less fraught with pitfalls, so I'd probably recommend that for your scenario.

#5313051 Cleanup and return from main in case of a crash or just display error message...

Posted by on 28 September 2016 - 09:56 AM

It's generally a bad idea if your library code does things like call MessageBox, exit(), or force process termination. You should catch the error and propagate it out across your library's API boundary. You can do this with exceptions or by returning error codes, or both. This is less of a concern if you're going to be the only person consuming your DLL, but it's still worth thinking about.


Separately from this is the idea that crashes and errors aren't the same thing. Failure to initialize D3D should not crash anything. It should be an error that is gracefully reported to the consumer of the library and in turn gracefully reports to the end-user.


There are various interesting things you can do with actual crashes, such as trapping them via Structured Exception Handling and gathering process memory dumps which you then save or upload to a crash server or whatever for diagnostics.

#5313039 Why do new engines change their file extensions and formats all the time?

Posted by on 28 September 2016 - 09:27 AM

It seems that backward compatibility is not possible when changing file formats.


Of course it is, and it's done all the time. Just because it wasn't done in the few instances you've observed doesn't mean it's impossible. It simply means it wasn't necessary or desirable for the developers, who could probably simply re-export their old source art into the new format more easily.

#5312953 Why do new engines change their file extensions and formats all the time?

Posted by on 27 September 2016 - 09:21 PM

When you use a piece of technology for a multi-year game development project, you learn a lot about how it works in practice versus how it works when you initially designed and wrote it. When you get the chance to fix all of the issues you identify with the technology at the start of the project, you usually take the opportunity to do so. Maybe you can reorganize the format to be more efficient for your actual use-cases, maybe you can add support for new bits of data in the storage format to allow for newer technologies that have come around or that an updated minimum specification lets you take advantage of... there's lots of reasons, and most of them are to serve practical needs of the project.

#5312349 Serious Question needs serious logical feedback

Posted by on 24 September 2016 - 05:36 PM

There is a point at which such conversations become fairly clearly an unproductive waste of time, but I don't think this instance is there yet. Nor do I think they are unproductive in general. Perhaps a bit naive, sure, but I still think it's fine to assume good faith on the part of the asker and deal with the fact that that assumption was unwarranted when it actually happens.

#5312138 Alternative to DirectX and XNA?

Posted by on 23 September 2016 - 10:53 AM

XNA isn't being developed any longer. It still works fine, though if you were starting with some new project you may be better served using MonoGame.


Direct3D isn't dead or dying at all.

#5312111 Serious Question needs serious logical feedback

Posted by on 23 September 2016 - 08:18 AM

Generally I don't see why questions like this are an issue or why we'd want to downplay them? It seems to me that the crux of the question fits well into the domain of the business forum.

I'd be interested in hearing why you think these sorts of questions shouldn't be acceptable, although perhaps as us own topic so as not to derail this topic further.