Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

Josh Petrie

Member Since 11 Jun 2003
Offline Last Active Private

#5225279 Steam's compensated modding policy

Posted by Josh Petrie on 24 April 2015 - 01:00 PM

For example, if I and another person (working professionally) were to start working on a mod for Fallout 4 right now



How are you going to work on a mod for a game that doesn't exist yet? I mean sure, there's some subset of work you can do, but a lot of real production work would be difficult with the shipped game and tools -- there's a risk that you'll build content that can't be used, or at least not directly. There's no guarantee that mod tools for a game on a likely-similar engine won't be updated with new rules/features/data formats. In fact it's almost a certainty. Seems like a risky proposition for me, especially since (in general) you don't even know if or when the game will support paid mods.



Would Valve allow this



Why is it their problem? It's the game developer who allows mods (paid or free) or not. Valve doesn't factor into that decision.


This seems to have the potential for a talented group to actually get a piece of the release-week gross earnings pie.


Sure, potentially. But as whether or not paid mods are supported is in the developers hands, you're taking a risk investing that time. It's possible that a developer won't turn on mods (or paid mods) until some period of time post-launch.
Also, can a game development studio actually compete with modding groups making their own DLC? I'm skeptical...


Absolutely they can, especially in the timeframe when studios typically ship DLC for a game. In that timeframe, they already know the tools way better than any modder would, they possibly have internal tools that are superior or provide better access/functionality, and they typically have significantly larger resource pools available. Studio DLC is for the short term post-launch. Mods extend the life of the game beyond that term.
Plus I'd argue that "competition" is not necessary nor even strictly the proper term. Skill modding groups making awesome mods for a game that generate revenue benefit both the modder and the developer, under Valve's program. There's no reason the developer needs to view modders in an antagonistic, competitive light in this scenario...and if they do they're probably not enabling mods anyway.

#5225233 Design: Managers VS Single Entities

Posted by Josh Petrie on 24 April 2015 - 09:42 AM

but mainly does this mean my "render system" is going to be tightly coupled to my current rendering objects or any future one's I create? 



No, exactly the opposite. Creating new things -- text, sprites, particle emitters, whatever -- involves appropriately crafting the data of an Renderable instance or instances and sending them to the RenderSystem. The RenderSystem only understands Renderables, and thus is not coupled to any specific use of them.


 And that I should be rewriting my current systems into one giant one instead of trying to keep them separated?



Yes, you should strive to have your rendering pipeline unified. Differences should be handled by data, not code, for as deep along the pipeline as you can. Your approach right now appears to have each type of visual thing directly know how to render itself through manipulation of the appropriate D3D interfaces, et cetera. Not only does this create the sort of state synchronization problems you original encountered, it's usually less maintainable because it's usually a lot more repetitive boilerplate code, and changing or adding features can involve having to touch a significant amount of that code.


The way I see it is that my render system is the highest level and the subsystems (sprite batchers, emitter, light, etc) are the medium level. Maybe I'm thinking of this wrong?


In the approach I am describing, you have OpenGL or D3D at the bottom of the stack. On top of that is the "RenderSystem," which abstracts away those APIs allowing you to speak in terms of "draw this geometry with these flags at the correct time." On top of that you build the highest-level visualizers for transforming you logical game data (tile maps, sprites, particle emitters) into appropriate commands or objects for the RenderSystem to consume.

#5225230 Steam's compensated modding policy

Posted by Josh Petrie on 24 April 2015 - 09:34 AM

The response is exactly what I'd expect. Of course lots of people are going to put their mods up for sale on the newly-available market for outrageous prices; that's what happens when a new market emerges. It will eventually self-correct. It's what markets do.


The idea of allowing modders to charge for their work isn't new, but in the past, been limited to individual studios supporting such a thing with individual games. Valve's approach here is probably the largest, broadest attempt our industry has seen. I'm in favor of modders being able to charge, if they wish, for the results of their hard work so long as the developer of the original game is okay with that as well; Steam's system allows for that as the developer must "build in" workshop support, so I'm in favor of it.

#5225134 Design: Managers VS Single Entities

Posted by Josh Petrie on 23 April 2015 - 04:41 PM

No, more like a "RenderSystem" object that methods to "enqueue" and "flush" objects of type "Renderable." A renderable object is a simple structure (not the base of some class hierarchy) that has references to geometry (vertex and index data), textures, shaders, and whatever other metadata you need to render (such as some flags to indicate sort order requirements, and so on). The render system simply enqueues these, sorting them as appropriate based on the data, and flushes them when needed (or demanded). This puts all the logic for dealing with batching, sorting, et cetera in one place. 


Higher-level systems (like a "particle visualizer") are built on top of that medium-level system. The ParticleVisualizer interface can take a *logical* particle system description and produce the appropriate renderable instance or instances, which can then be fed to the RenderSystem.

#5225059 Best Program for Beginners?

Posted by Josh Petrie on 23 April 2015 - 09:59 AM

In the future, please take discussions about whether or not responding to a particular thread is worthwhile (because the use is being a "help vampire" or otherwise) to another thread, or flag the thread for my attention. Don't derail the whole thread with that discussion.



#5225057 What could I hypoteticly face for reused asset I do not own

Posted by Josh Petrie on 23 April 2015 - 09:52 AM

Lets say the game gets commercial, earns money



Largely irrelevant.


I wonder, what possibly may happen to a subject that creates a game while incorporating an asset that it did not create




The worst that could happen? Legal action. You lose lots of money. Probably money you don't have. Details depend on your jurisdiction, but generally this sort of thing is covered by copyright and/or intellectual property laws that you'll have violated.


Don't do it.

#5224861 Design: Managers VS Single Entities

Posted by Josh Petrie on 22 April 2015 - 09:26 AM

Is this something I should even consider / whats the best approach?


"Best" is subjective, but having a renderer interface responsible for properly sequencing all draw requests is a pretty common pattern. I'd say it's worth looking in to, as if nothing else is does afford you the opportunity to make it harder to misuse your rendering architecture in the way you've currently demonstrated. It also implies that your rendering code (the stuff that actually deals with OpenGL or Direct3D underneath your API layers) will be more centralized in this rendering interface rather than scattered about over "sprite batches" and "particle emitters." 
You can still have higher-level render objects like that, they can just be written in terms of your rendering interface so the onus of the sequencing (and begin/end pairing) is not on the user of the code any longer.
Should I have done this in the first place?


If you did, you may never have stumbled across the flaw in your initial design that taught you the alternative your thinking about might be better, and thus you would not have understand the relative pros and cons as well.
Would it just be better to have the separate entities and "flush/draw" when I know I need?


It's generally better to have a single renderer that knows how to draw "renderable objects" rather than spread rendering code all over other entities. It centralizes the functionality for extension and optimization and removes responsibilities from other interfaces that may not need them. 
Does the Singleton pattern apply here / will I fall into it's "trap" (I kind of don't really understand the Singleton pattern trap)?


You can trivially avoid the pitfalls of singletons by simply never considering them as a design option. You'll be perfectly fine doing so; there is no need for a rendering singleton here.
If I had a render manager


"Manager" is often a bad word to use. It's too broad, implies too much fuzziness in the individual responsibilities of an interface. There are usually better, more-specific words you can use to describe the name of such a thing, and you should use those if possible. In this case what you are describing is an interface which takes draw requests and then flushes them to the card in the proper order with the proper set up and tear down. It would not be out of place to simply call this a "renderer," but if you are using that name already, other common names for the kind of thing you're talking about are "render queue," "render command stream," and "render sequencer."

#5224576 software contract (good or bad)

Posted by Josh Petrie on 20 April 2015 - 05:04 PM

What do you guys think?



Sounds like a bad deal.

#5224514 Resume/Portfolio Feedback (Game Programming graduate)

Posted by Josh Petrie on 20 April 2015 - 10:55 AM

My thoughts:

  • I am generally not a fan of "about me" sections or sections where you list out a bunch of "relevant skills" with "years used" values. I consider them to be content-free space-fillers. I assume you are interested in games since you are applying to a game development studio, and I assume you have at least a basic proficiency in programming (which I will likely test on my own). Years using a tool doesn't really convey useful information about your abilities; I want to see what you can do with a tool (and I expect to see that covered under your projects), not how long you've used it.
  • I like that you call out leadership/mentorship roles in your education section. Expect to be asked about them.
  • It's good you provide links to actual code on your resume (for R2DEngine). However, you should use a .gitignore to clean up all the user-specific and/or transient junk files in your repository (mainly the .psess and .vspx files with generated names, along with the .tmp files). It looks sloppy, like you don't care.
  • The project entry for R2DEngine is the best one; it provides details (although more details would be better) about how and what you did what you did. The other project listings are less good; they just list extremely high-level tasks you performed without details on what that involved, why it was cool and why I should be interested in or impressed by it. I'd suggest fleshing those sections out.
  • When you say that you "implemented something using the X design pattern," that's a red flag for me. It suggests you think about design patterns as pluggable pre-built solutions to problems rather than simple vocabulary. It's a hallmark of an inexperienced programmer, in my opinion.
  • I don't think any of your "work experience" is necessary. 


I'd suggest fleshing out each of your project sections with more details on interesting tasks you accomplished and why they were challenging or unique. Drop the "about me," "skills," (you can work these in by mentioning them in the projects section) and "work experience" sections if need be. Link to more source code if you can -- your R2DEngine code is a good start but after poking around the code randomly, I see several red flags that I'd probably ask you hard questions about at an interview. Consider dropping less interesting projects in the name of making your resume fit on a single page.

#5224505 Remaking Mario 64 from scratch, how long?

Posted by Josh Petrie on 20 April 2015 - 09:53 AM

How long would it take with today's technology to remake almost all of Mario 64 for one person with no previous skills in 3D gaming, but with pretty good skills in 2D gaming?



#5224501 C# System.Drawing.Point

Posted by Josh Petrie on 20 April 2015 - 09:46 AM

Here is the best practice advice on structs direct from MS





The document you are linking to are the framework design guidelines. These are documents that describe guidelines that Microsoft uses when writing the .NET framework libraries and, to some extent, other libraries that must interact with the CLR across potentially many CLR-compatible languages. While many of them are also applicable to your own applications, they should not be considered hard-and-fast rules or generalized "best practices." They must always be taken in context. Even within the framework itself they are just guidelines. They provide initial direction but the implementing engineer is always expected to discard them if there is an acceptable reason within a specific localized context.


Further, System.Drawing.Point predates the existence of those documents as a public resource, and the note on immutability concerns was only added in the framework 4.5 version of the document. They didn't "get it so wrong."


Mutable value types in the CLR do have a place; points and vectors are an excellent example. Specific instances will likely change often and/or be created and destroyed frequently. The latter strongly suggests you may not want to heap-allocate them to help avoid GC churn (especially if you continue to model them as immutable), but the former implies you won't want to introduce the tedium of immutability in the actual process of writing code that manipulates them (which, in this case, isn't going to offer you a whole lot of advantage anyway).

#5224172 Investing into a Game Project

Posted by Josh Petrie on 18 April 2015 - 08:59 AM

Hey guys. I was lucky enough to inherit some money and part of that money i would like to invest into a game project. 



Congratulations. Might I suggest you pile it all in your back yard and set fire to instead? It will likely be a far more entertaining use of the funds and will have about the same net result.


Im lookin to put aprox about $30k-$40k

Is that a decent amount to create a decent project?



It depends on what you mean by "decent," but in all likelihood, no, that is not on it's own enough to create a decent project. Certainly not one with a reasonable likelihood of giving you any kind of return on your investment. It will likely get you the salary alone for a single developer (for how long depends on how skilled a developer), and possibly some overhead costs. It will go further if you're planning to invest it into a pre-existing project, but that's not the impression you're giving.


I currently dont have any ideas about what game or what engine or whatever im gonna do.



Now this is confusing. Are you going to invest that money (with the hope of return), funding somebody else to make a game, or are you going to use that money yourself to buy yourself the tools, technology, et cetera you need to make a game? They are very different things.


Game development is not a safe investment, especially if you are not very familiar with the industry. I strongly encourage you to take that money you've got and pay yourself with it instead: ensure your emergency fund is well-stocked, pay down all your debts, and put the rest aside for longer-term financial gain by maximizing your contributions to tax-free or tax-advantaged account instead. Any reasonable financial advisor can help you with this (and will probably also strongly caution you off making such an extremely risky investment as trying to fund a game development project as well).

#5224081 Help Regarding Development Jobs Applications (and Rejections)

Posted by Josh Petrie on 17 April 2015 - 04:12 PM

Josh makes a case for supporting '+' as a prefix



I didn't mean you should support it, per se. I just noted that you didn't and asked why. Many times there are choices which are not obviously good or bad, and you'll need to make a decision about how your function will behave under those scenarios, and you should be prepared to define your choice.

#5224052 Question regarding game development

Posted by Josh Petrie on 17 April 2015 - 02:05 PM

If I work for a company to make a game can I leave at any point and start my own company?



Yes, unless you agree to a contract that says you can't. Typically these clauses are called "non-compete" clauses, and they may or may not be enforceable, although that's really a non-issue since you don't want to bother with the time and money required to fight the clause legally. Save yourself the trouble and strike any such clause from your employment agreement. It's also possible that your employment agreement will impose certain criteria on your employment duration, notice period, et cetera. Basically, read and understanding the things you sign.


Will they be enthusiastic about teaching me how to make games



An employer isn't going to teach you to make games. If they hired you it's because they expect you to have some basic proficiency in doing so already. You will learn things on the job, of course, and that is to be expected. If your ultimate goal is to start your own studio, keep that to yourself.


will it be impossible to go back to them ?



That depends on the company and the circumstances under which you left their employment.



I doubt I will ever make it into the industry though



Not with that attitude you won't.

#5224000 Help Regarding Development Jobs Applications (and Rejections)

Posted by Josh Petrie on 17 April 2015 - 10:26 AM

If you're getting feedback that your C++ is not up to par, you should pursue improving it. One way to do that would be to take a project you're working on, or a reasonable chunk thereof, and post it somewhere on these forums for critique and review. It's really hard to give you any additional general advice, given the lack of information you have about why you've been rejected from the positions. It's important to remember that it isn't always because you were bad, it could very well be that somebody else was better.


Further, in interviews, you often get asked simple programming questions for a few reasons, and they're not all to do with gauging you ability to actually write code. Simple problems allow an interviewer to get an insight into a more complete picture of a candidates approach to arriving at a solution. For example, you said that you were asked to write a "function which given an integer could produce a string," and showed us your answer. I can tell from the first line of code that the function you wrote converts a string to an integer; this is the opposite of what you were asked and suggests inattentiveness to detail (unless it was just a mistake when writing your post). 


As for the function itself, some things to consider:

  • Why is the parameter "c" called "c?" What's "c" mean? Why not "string?" Or something equally more-descriptive?
  • Why is c not const? Are you going to modify c in the function? Do you need to? What benefit or drawback would adding const provide?
  • You dereference c before checking if it's null. What should happen when the caller passes null? Why is that behavior good behavior? Why is that behavior bad?
  • What's 45? Magic numbers are bad. Given the context in which you're using it I can assume (and confirm) that 45 is the ASCII code for the minus sign. It would be better to write this as "if (*c == '-')" since it's more obvious, and in general it's better to use symbolic names for most constants instead of magic numbers.
  • Why do you support a leading - but not a leading +?
  • As above, what are 48 and 57? Magic numbers are bad.
  • The entire first loop is basically strlen. Why not call strlen?
  • Why do you want to do this in one loop instead of two? Can you? What is the trade-off of doing so?
  • What happens if the input is not a number, or is a partial number like "-23abbbabba"? Why is this good behavior or bad behavior? What alternatives did you have?