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

#5237876 Real-time RPG Framework design

Posted by Josh Petrie on Yesterday, 09:26 AM

You're right your question is too vague. If you really want advice for structuring the code you need to be able to more clearly specify what your needs for a system are and what your current problems are with respect to implementing or designing that system.


That said, your plan strikes me as a bad idea. For two main reasons:


  • You have no budget. This means you're basically bleeding money in opportunity cost (that is, the time you're spending producing this game that's currently making you no money is time that could be spent doing something that directly makes you money). 
  • You can't answer the very basic questions about the design of this framework, which strongly suggests you're trying to build a system too far beyond your scope and which encapsulates requirements you don't actually need or haven't actually defined.


I think you'll be better off simply working directly on your game. Don't work on a "generic framework," it's going to take more time in the long run as you struggle with problems you don't actually need to have and thus decrease the net profitability of your game. A "generic" framework that hasn't actually been proven to be generic enough to ship multiple games on won't fetch a very high price as middleware, and similarly reusable code is only useful if it's actually resuable and proven to be so... claiming that you're writing it doesn't make it so, and you generally need to put it through it's paces anyway to know whether or not it is.


Instead, focus on writing the game you want to write. Refactor things as you go and notice you could make them reusable across different aspects of the game. You'll ship sooner, and once you ship and start making money you can take a breather, assess what you want to do next and what the strengths and weakness of your codebase are (based on what you learned while making an actual game), and take the reusable parts forward to your next game.

#5237793 C++ as a scripting language

Posted by Josh Petrie on 30 June 2015 - 09:20 PM

Yes, and it's not a good idea.


If you're talking about "scripts" that are extremely high-level... more like a plugin with very defined entry points via a C ABI (so none of the "crazy template" stuff)... then it can work. Alternatively you can get slightly lower-level if you know you're going to be in full control of the scripts (that is you write them all yourself), but you're getting into some questionable territory there (why go to all the effort, why not just put the game code in a static library and link it and save the mess?)


There are a handful of interesting and/or academic reasons to do it, but these days they don't seem very practical in the face of better alternatives. Either write the game code in C++ or write the game code in a scripting language but don't waste the time and effort trying to build Frankenstein intermediate solution. That way lies peril.

#5237515 Roles

Posted by Josh Petrie on 29 June 2015 - 10:39 AM

How many programmers does an indie games usually have?


Depends on the game, there is no good "usually." Even the definition of "indie game" is a bit varied, but generally you can expect anywhere from one to a small handful of developers on such projects.
Are these roles descriptions correct?


Definitions of roles are vary widely from project to project or studio to studio. The descriptions you've provided seem reasonable enough for a *specific* game but aren't necessarily broad enough to apply industry wide. They're more like narrow examples than definitions.

#5236936 c++11 lambdas: best practices for 0 dynamic heap allocation?

Posted by Josh Petrie on 26 June 2015 - 10:01 AM

Edit 20-bajillion: Stop messing with my formatting stupid editor... 


Good luck with that.

#5236592 DigiPen: Computer Science and Game Design vs. Computer Science

Posted by Josh Petrie on 24 June 2015 - 12:30 PM

"Top 50 lists" are, generally, crap. If you're going to consult one, make sure you read up on who is doing the selecting and what the selection criteria is. Usually it's not who you would expect, nor are the metrics what you'd expect. If you can't even get that information, definitely stay away from the list.



"Game degrees" in general are not something I'd recommend. That isn't to say you can't be successful by getting one, and ultimately you need to do what you think is right for you -- if you really want to go to DigiPen, go right ahead. It's not so bad that it's going to prevent you from ever getting a job, or anything, and certainly there are some advantages to the school over more traditional schools. It's just not something I would recommend. I would recommend you get a four-year degree in computer science from a good school that you can afford.

#5236573 C++ babysteps

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

I don't really think this little conversational tangent is relevant or helpful to the OP at this point, so please stop.

#5236570 DigiPen: Computer Science and Game Design vs. Computer Science

Posted by Josh Petrie on 24 June 2015 - 09:21 AM

Note that as an alumni and as a hiring manager, I wouldn't recommend DigiPen particularly highly.


That said, you've stated you want to be a programmer, so the "real time interactive simulation" degree is likely the one you'd want to pursue. It is as close to a "regular" computer science degree as the school offers, and it's also the older and more mature of the degree programs. You will have plenty of opportunity to practice your design skills during your team projects or on the side (the school is not necessarily all that strenuous).


Neither program will offer you much in terms of "management skills" beyond team interaction, which you'd get on anywhere from any program that ever has you work in teams for anything, so I wouldn't use that as a point for the game design degree.

#5236379 what really get and set do?

Posted by Josh Petrie on 23 June 2015 - 11:15 AM

You don't have to start with a property to be allowed to refactor something.



No, but it is worth noting (in the general sense and to the OP) that a property isn't a field (although one might be involved behind the scenes): you find them differently via reflection. So if reflection ever might be involved, it's a consideration in whether to start with a field or a property since the distance from field to property-with-custom-getter-or-setter is larger than property-with-trivial-getter-and-setter to property-with-custom-getter-or-setter. If only slightly.


For this reason I generally always use properties, and rarely public fields. The inability to reference the property has never been a serious issue in any of the code I've written anyway.

#5235735 Interpreting unordered_map key as blob of bytes for hashing?

Posted by Josh Petrie on 19 June 2015 - 12:14 PM

I dont know what operation to use to combine the hashes in place of '?', and I dont know if doing this is going to weaken the hash and introduce more collisions or such.



Okay, so turn it around, you have an array of bytes, which you compute the hash of by doing hash(byte[0]) ? hash(byte[1]). Same problem.


As Sicrane said, summing is probably unlikely to be a good choice for '?'. 


And the hash functions themselves probably run faster if they have a contiguous string of bytes instead of doing it one member at a time.



Not likely. Member0 is likely quite next to member1 in memory, after all. And if you have members which can be efficiently hashed as a whole (integers larger than a byte for example) as a constant-time operation, member-wise hashing may reducing the constant factor of the hash's time complexity anyway over byte-by-byte hashing anyway.


In both cases it's unlikely to matter.

#5235706 Interpreting unordered_map key as blob of bytes for hashing?

Posted by Josh Petrie on 19 June 2015 - 09:49 AM

What's wrong with hashing each member together and combining the resulting hashes in some appropriate fashion, exactly? That's the typical approach. Reinterpreting the key as an array of bytes is also doable, but in some cases is basically the same algorithm in a different shape (and you'll want to be aware that compiler-insert pad bytes might change the hash if you do it this way, which is bad).

#5235494 Hi there, freshman here =]

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

i don't know if i should stay in Java for the mean time and do some basic work in it, or move to a different language




Stick with the language you already know.


i mean, knowing how to program stuff is one thing, but knowing how to create a game is a bit different.




Making a game is programming. It's not magic, it's not fundamentally any different from programming just about anything else.


One could make that Time Fantasy game in Java quite reasonably, if one had the skill. If you claim you've finished other "basic" games like Tetris and whatnot, then try your hand at something you think is more challenging. Perhaps try making a basic tile-map engine with some 2D sprites that can walk around and collide; that's one of the basic building blocks of the game you linked anyway.

#5235389 Beginner in programming and game development!

Posted by Josh Petrie on 17 June 2015 - 10:10 PM

Unity is fine. Keep making (and finishing) games.

#5235314 .NET Developer -> Video Game Developer?

Posted by Josh Petrie on 17 June 2015 - 12:34 PM

You should absolutely not consider an internship. There's nothing all that special about game development; programming is programming. There's some domain-specific stuff you'll want to learn or pick up on the job, but a good programmer is a good programmer regardless of the industry, for most part.


So you should take an actual full-time programming position. Salary-wise, you should take a look at the cost-of-living in the area you'd plan on moving to if you take the job and use that as the basis for what you should expect.

#5233920 Not Getting A Degree...

Posted by Josh Petrie on 09 June 2015 - 03:42 PM

Would it really matter to a company whether I had a degree which included those classes or if I had certificates saying the same thing? 



Yes, the degree will likely be considered "worth more," all other things being equal. This industry is filled with excellent developers who don't have a degree, but that doesn't mean that it's easy to get a job without one. Especially in the current job climate.


Wouldn't it make more sense to directly learn the things I would need to get a job in the industry rather then take all the required extra classes you have to take in order to get a degree?



You're assuming you know for a fact that those "extra classes" are extra and not relevant to your future work in the industry. But you're not in the industry, so you should be careful with such assumptions.


Those extra classes usually contain a lot of general information that many people would expect you to have, and a lot of it may be surprisingly useful. They add breadth to your knowledge, which is desirable: you depth in a few key areas and breadth in as much else as possible. Almost everybody in your position has your attitude: that you somehow know better, and that you can tell right now that you will or won't need the knowledge of some particular class.


After a few years in the industry you'll end up on the other side of that spectrum, thinking "huh, I'm glad I learned that way back then" or "huh, I wish I had taken that extra class on computational topology, this would be much easier to understand now." And if nothing else, slogging through those "useless" classes shows you can slog through things you don't necessarily want to do. This is a necessary real-world job skill if you want to remain employed anywhere.


Finish the degree. Most "certifications" are worthless in the games industry.

#5233600 Game programmer - career change

Posted by Josh Petrie on 08 June 2015 - 01:39 PM

I think you're already a software developer, so you can already write code, so you should just apply for programming positions in game development companies if that's what you want to do. People get hired from outside the industry all the time.