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

#5212565 How were you learning programming at the age of 5?

Posted by Josh Petrie on 23 February 2015 - 05:31 PM

"Learning programming" at such a young age is nothing like learning programming at an older age, but still very possible.

 

Rather than learning syntax and keywords, like you might now, young children can be exposed to simple logical concepts such as associations between interface and action, storing things for later, and breaking complex ideas down into simple ones ("complex ideas" for a five year old are very simple already, so this is particularly straightforward).

 

Children are knowledge sponges, and framed the proper way and with the proper high-level tools you they can learn a lot of surprising things. But you won't be sticking them in front of a terminal with vim, gcc and the Rust user manual and expecting them to learn that.




#5212562 Epic List of Interview Questions

Posted by Josh Petrie on 23 February 2015 - 05:28 PM

Most interview questions don't have a "correct" answer, per se, in the sense that point of the question is not for you to spit out a quick response and move on to the next question. The point is to engage you in a conversation about a subject (usually technical).

 

Many of the questions on the site you've linked fall into three broad categories:

  • questions about experience with programming concepts,
  • questions about academic subjects typically covered in a computer science degree program and
  • questions about generalized problem solving (the kind you'd have to do at a high level before committing to code)

The first and third are the kinds that generally do not involve the interviewer expecting a single "correct" answer (although they may have an internal bias); so worry less about being correct and more about explaining yourself and your thought processes. The second kind does tend to be more about specific, optimal solutions. If you haven't completed a computer science degree you may find them daunting, but some self-study in the areas of data structures and computational theory can alleviate some of the gaps in your knowledge.




#5211924 who really a creative director is?

Posted by Josh Petrie on 20 February 2015 - 10:50 AM

i want to know who really he is, because i think its the most important post in game process and always we see creative directors interview about their games.

 

 

It means whatever it means to whatever studio gives an employee that titles. Job titles in the games industry are not in any way standardized, and the role of a "creative director" at any two different studios may vary widely.

 

It is generally shortsighted to think that there is a "most important role" in the process of game development: they are all fairly critical and without any one of them, the others will suffer, occasionally to the detriment or failure of the project. 

 

 

You generally see two classes of people (from large studios) talking about games to the press: designers/creative people (because what they can talk about with authority tends to resonate more with a broad base of consumers) and employees who are high up in the management hierarchy (because they often serve as frontspeople as part of their daily roles, and generally have a broader view of everything going on in a project). In many large studios, no-one is allowed to speak to the press unless they have undergone some form of press training, and generally is it easier to train a fewer number of people, which is why you often see upper-level management from design and production roles being interviewed.




#5211707 How to start educating yourself with programming from scratch

Posted by Josh Petrie on 19 February 2015 - 11:05 AM

Would you give me links that helped you to learn?

 

 

I learned to program before the web was a thing.

 

Is C++ really going to be obsolete soon and not used anymore? Or are there games out there will still be built on it in the future? Because I know my favourite game is based on C++ and using an Unreal Engine... That's why I was thinking to start C++.

 

 
In some respects the language is obsolete now, from the theoretical perspective of modern language features and design. However, from a practical perspective it's nowhere near obsolete and will remain in heavy use for a long time to come.
 
That does not make it good first language, however. It's very complicated and very unforgiving - it's very much focused on the idea that you, as the programmer, know exactly what you are doing. You, as a neophyte programmer, don't know exactly what you are doing so you will find the language far more of a struggle. C++ will be much easier to pick up once you have learned another language first, and good programmers know many languages anyway.
 
 
What your favorite game was made in is about as relevant to your ability to make games as the color of my car. The developer makes the game, not the language.
 
 
About that C# free course. It sounds interesting but it sounds like it's not as professional as C++ or Java. If one was to learn it and go through with it would it then greatly help to learn C++ after?

 

 
This statement comes from a position of naivette. There is nothing "professional" (or not) about a language, only about the programmer. And a professional programmer does not scoff at a useful language.
 
If you learn C# (or Python, or whatever) first, then yes, C++ will be easier to learn because you will have already spent time learning lots of fundamental concepts that will transfer and make your life easier.



#5211703 Am I wasting my time with this

Posted by Josh Petrie on 19 February 2015 - 10:54 AM

I would hardly consider the update frequency of MonoGame's site to be that serious of tell for anything. Rather, look instead at the update frequency of the project itself. MonoGame is far more actively developed and supported than XNA (XNA is end-of-life'd, so I'm not sure why anybody would suggest XNA over MonoGame unless you desperately wanted to get onto the 360, or as a suggestion to only use XNA's content pipeline, because MonoGame's variant is still young).

 

Further, there's lots of resources available for getting help with MonoGame: their community, this community, StackExchange, et cetera. Books... sure, maybe less so, but books on specific APIs are usually a huge waste of money anyhow. 

 

I don't think you'll waste your time using MonoGame. 

 

Unity is another good option, but you're correct that you will be learning to do things largely the "Unity way" which may not transfer elsewhere. And, more importantly, Unity will be providing you a higher-level framework to work within. This may or may not be important to you.

 

I think you would be wasting your time abandoning the language you already know well for something like C++, which is difficult to learn, far more tedious in many ways to work with (especially compared to C#, and especially when you don't know C++ well) and is riddled with libraries and frameworks that do have all the original issues you described anyway.




#5211565 Battle Programmer?

Posted by Josh Petrie on 18 February 2015 - 05:03 PM

You assume incorrectly. The position you want basically doesn't exist.

The closest equivalent *actual* position is probably a "gameplay programmer," however there is no guarantee that your work in such a position will only involve combat mechanics or cutscenes.

(Many Japanese RPGs have people credited as "battle system programmers," these are generally the same as gameplay programmers and tend to reflect the different role nomenclature and title standards in Japan more than anything else.)

The good news is that gameplay programming positions vary widely from studio to studio in their day to day tasks and consequently they do tend to exist as entry-level positions.

Unfortunately as an entry-level programmer you will have to spend some time as a junior before you are really given engineering authority over the entire combat system of a game.

Still, it is very achievable.


#5211547 How to start educating yourself with programming from scratch

Posted by Josh Petrie on 18 February 2015 - 03:56 PM

Or is it possible to learn C++ just by reading through articles and such posted on forums?

 

 

 

No, you also have to build programs with it; you don't need to spend money, though. There are plenty of good resources available for free on the internet.

 

But C++ is a really bad choice for a first language.




#5211308 Resource objects in stl containers

Posted by Josh Petrie on 17 February 2015 - 06:17 PM

You can use move semantics (introduced in C++11, so you'll need an appropriately modern compiler) and write the appropriate move constructor for your object (and assignment operator).

 

If you can't use move semantics, reference counting is a reasonable option (and perfectly clean).




#5211263 What are the recommended places to store save data?

Posted by Josh Petrie on 17 February 2015 - 02:32 PM

A quick Google search reveals this informative post detailing the best place to put data for each platform (mostly mirrors what's already been said here). Unfortunately though, there still seems to be a lot of difficulty in getting everyone on board with the same "standard" data paths, especially on Windows, since there are a ton of folders that have been added over the years where you could arguably put "user data" and not necessarily be wrong, even if it isn't in line with everyone else.

 

 

If only we had a tool... that users run before playing a game for the first time... that could could ask them where they want their saved games?

 

Nah. That'll never happen.




#5211224 What are the recommended places to store save data?

Posted by Josh Petrie on 17 February 2015 - 11:20 AM

I really wish it was standardized and had to be placed in one spot.

 

 

 

It is standardized. Unfortunately that's largely irrelevant because lots of people just ignore the standards, because they think "they" are special and deserve to clutter up your "documents" folder (instead of %AppData% or Application Support) with their own hierarchy of folders and saved games and crap.




#5211055 Entry level game design positions, are they a viable route?

Posted by Josh Petrie on 16 February 2015 - 03:47 PM

My main question was should I risk making my portfolio for future jobs (not the internship) in game design?

 

 

There should be no risk here; the portfolio is of your work. That will be equally applicable to any job you apply for. It's the work you've done. Unless you're trying to build your portfolio out of pieces you've tailored to a specific job or job application, in which case you're doing it wrong because most of the time that kind of thing is easy for a potential employer to see through.

 

Most game designers got to where they are after being level designers and many other positions over the course of 10 or so years.

 

 

 

Citation needed. But probably irrelevant anyway, because (a) "most" game designers are not you and (b) "most" game designers have been in the field a while, meaning they were part of the industry when it was younger and different than it is now.

 

 

Now there are entry level positions that did not exist 5 years ago and can get you to upper tier game design jobs far faster than the route that I just mentioned.

 

 

This is just wrong. First of all, entry level positions have always existed: everybody started somewhere. It is true that they have not often been heavily advertised, but generally this is because they didn't need to be. There are always potential internal candidates and unsolicited candidates. 

 

Second of all, unless your first position in the industry is an "upper tier" (what does that even mean, exactly?) position, there is nothing about an entry level design position that will get you there any faster. Your ability to reach an "upper tier" job (whether that be about salary and compensation, final deciding authority over a particular aspect of the game, management of juniors, or simply an empty job title) is all down to one thing, really: You. Your ability to do your job plus handle those additional aspirations well. Unless you work somewhere where nepotism or pure seniority factors 100% into promotions (and you don't want to work in those sorts of places), it's how well you do at a job that's going to get you promoted or otherwise advance your career. Not some arbitrary metric based on what your title was in your very first job.

 

This is why many young game designers have been popping up lately, people in there mid to late 20's.

 

 

Such as? I have not seen a rash of game designers "popping up" recently, unless you count hobbyist and independent developers who

 

  • are generally working alone/for themselves, and thus are part of a system wholly distinct from the corporate/studio process you're talking about entering
  • have always, always existed and simply appear more prevalent now (and have much better success rates) because of the way the modern internet has evolved extremely useful tools for them (social media, Kickstarter, Steam and the like)

 

 

So I would just like to know whether it would be worth the risk to try and make a portfolio for these rare entry level jobs in order to rank up faster in terms of the game design tree, or should I follow the more traditional and reliable route of becoming a level designer or something along those lines to try and become a game designer. It comes down to if I want to risk not getting jobs as easily but have the opportunity to become a game designer is my 20's rather than my 30's or 40's.   

 

 

Just... no. You have a very naive view of the industry in a lot of ways -- as is typical and expected of somebody who, you know, hasn't actually been in it for the last ten years. 

 

Here's my advice. As somebody who has.

 

  • Your portfolio should be about you, about work that you are proud of and that you did because you loved to do it. That work will show the best and provide the best platform for having interesting conversations about your skills and aspirations at an interview, which in turn makes you far more appealing a candidate than if you, say, tried to guess what the employer wanted to see and built that.
  • Job titles vary wildly from studio to studio. What is a "level designer" in one studio may be a "level artist" in another. What is an "entry level designer" might be functionally equivalent to a "level designer," obviating the entire need for your worrying about the distinction. Don't get hung up on what title you want, focus on what tasks you want to accomplish. Now, and for your longer-term career. There are entry points for everything, and as long as they broadly in the same domain as what you want long term they're going to be perfectly fine for you. You are never going to be a good "lead designer" if you don't have a good, basic understanding of all of the design tasks you are leading.
  • Similarly, game development isn't itself a game. There's no "tech tree" you can short-circuit to "rank up faster." It doesn't work so clean and simple like that.



#5211044 Entry level game design positions, are they a viable route?

Posted by Josh Petrie on 16 February 2015 - 02:56 PM

So my question for you is, do you think that it would be a viable option to pursue in terms of a portfolio for an entry level job to try and get?

 

 

Yes. Actual work experience will always in general be better than personal/side-project experience.

 

Needless to say this would limit me in terms of job opportunity's in the future due to the fact that many companies do not offer the position.

 

 

 

I don't see how this make any sense at all.

 

My thing is that if I manage to nail a job in the entry level version of game design than I could reach the lead game designer position in 1/4th of the time

 

 

Um, no.

 

So what do you think I should do?

 

 

It's unclear what you are asking. Are you asking if you should take the internship if they offer it?

 

If you can afford to relocate yourself, and afford to live there during the internship on what they pay you, and if it will not adversely affect your schooling, then sure. It seems like a good opportunity to learn and get practical experience.

 

Internships are rarely work-to-hire though, do not count on that.




#5211043 Pointers to array blocks.

Posted by Josh Petrie on 16 February 2015 - 02:48 PM

Adding the vector/array header, doesn't it add quite a lot to the executable size?

 

 

No.

 

 

Not unless your compiler and linker are crap. The array and vector classes are templates, and so will involve the generation of code that will end up in the final executable. It's likely that this will be slightly increase the executable size relative to not using templates and hand-rolling everything yourself. However, it's going to be much, much easier for you and far less bug-prone. It will almost certainly be a negligible cost.

 

Does gcc v3.4 already supports (nicely) stl arrays?

 

 

Probably has a decent vector implementation; doesn't have std::array. Why are you using tools that are almost a decade old?

 

Accesing the array/vector secuencially will be as fast as a C style array?

 

Yes.




#5211007 Exclusive maximum in random functions

Posted by Josh Petrie on 16 February 2015 - 11:30 AM

I really don't like a randomization lib being modelled only for indexing arrays, but the fact that everyone does it this way is a much more convincing argument. Before I go make a decision and move on, is there something I'm not thinking about?

 

 

 

If everybody was jumping off of a bridge...

 

There are pretty good reasons for why exclusive upper bounds in ranges are common. Despite those reasons I've always found them more annoying (I like to produce values between 0 and 1, *inclusive*, as floats often -- I'd rather be calling random(0.0f, 1.0f) than random(0.0f, std::nextafter(1.0f)) everywhere, as a result), and it's pretty trivial to make either convention work for all cases so long as you know the convention. 

 

So.... you can argue about which way to do it all day. In the end, pick the model that makes the most sense and will be the easiest to use for most cases for your users. Whichever you pick, document it. Or hedge your bets and offer foo_exclusive and foo_inclusive methods. 




#5209836 8 Tips for Aspiring Match 3 Developers

Posted by Josh Petrie on 10 February 2015 - 12:18 PM

For Beginners is for beginners to ask questions, not for you to spam links to your allegedly-for-beginners guide.






PARTNERS