Jump to content

  • Log In with Google      Sign In   
  • Create Account


We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.

Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!

Josh Petrie

Member Since 11 Jun 2003
Offline Last Active Private

#5128626 C If Statement Question

Posted by Josh Petrie on 03 February 2014 - 10:21 PM

This sort of thing is generally considered "bad" (using a ternary operator to wholly replace an if-statement):


(grade >= 60) ? printf("Passed!\n") : printf("Uh-ohhh...\n");


Generally, you should prefer an if statement to the ternary operator if the operands to the ?: are verbs or complex expressions with side-effects (as they are above: printing). 


The second example is a more acceptable use of the ternary operator:


puts(grade >= 60 ? "Passed!\n" : "Uh-ohhh...\n");


#5128625 The gaming industry, advice!

Posted by Josh Petrie on 03 February 2014 - 10:15 PM

However I have zero expirence with programming and little expirence with art design on computers. I do play a handful of games from triple A titles like bf4 on pc  to indie games like insurgency standalone and rising storm.



You should work on getting some experience with either or both of the first two topics. Making games is fundamentally different from playing them; while it's generally a nice perk that you are interested in playing games a hobby, it's not going to get you a job.


Through research I found many people to have worked long hours starting off as things like game testing were the pay is bad and the labour is intensive,


The industry has a reputation for being tough, but it's not a universal truth. You don't have to settle for extreme hours of unpaid overtime (and you shouldn't; when you do you only contribute to the problem). You also don't have to start in QA (and I don't generally recommend it), and it is not necessarily any easy to use QA as a stepping stone than it is to just get the job you actually want right off the bat (that is generally an exaggeration passed off as reality by clueless gaming press).


how easy it is to find a job, pay, hours of work, enjoyable, stressfull,  and is it a longterm career that is worth looking into, what education do I need.


It depends. If you are good, it's easy to get a job. If you are smart and self-confident (and not wholly risk-averse), the hours are normal. Whether or not it's enjoyable a stressful is very subjective, but it's certainly a viable long-term career path.


The education you'll want to get depends on your area of interest. If it's programming-related, you'll probably want a computer science degree. Art, probably some kind of art degree. Et cetera.


also a side note Is would it be good to start small and purchase game maker and create a 2d platformer, me and my freidn are interested in making a game like spelunky and possibly finding a way to sell it.


It is always a good idea to start small, and always a good idea to work on and finish game projects. It's highly educational and can eventually give you some awesome portfolio pieces. And maybe even make you some money along the way.


Be careful about spending money outright though; if a tool has a trial version, make sure you try it out completely before paying. You can make games without paying a single penny, so don't throw down your hard-earned money until you know you need (or want) to.

#5128624 C# vs C++

Posted by Josh Petrie on 03 February 2014 - 10:07 PM

This has been asked and answered several times over on this forum; please use the search functionality available in the upper right.

#5083877 Is Python underestimated with what it can do?

Posted by Josh Petrie on 07 August 2013 - 08:58 AM

This is no longer really relevant to beginners, so I'm going to close it (unless some other moderator wants to reopen it and move it to a more advanced forum).

#5080466 Why companies still use C++ and what should I learn then

Posted by Josh Petrie on 25 July 2013 - 09:22 AM


Legacy code, and lots of it.


Why is there so much legacy code for C(98) and C++(pre tr1)? Why not VB6, Java 1.2, .NET 1.1 or other popular languages or platforms of past years?


In ~20 years, sure we will probably call things like SDL legacy and sure people will still be slating C++ against their new language of choice and yet C++ will still be going strong, SDL will still work and everyone would have long forgotten .NET, C# and XNA.



Washu was talking about the game development industry, predominantly the professional portion of it. There is almost no "legacy code" for VB6, Java, or .NET because it is almost never used for shipping professional games. Additionally, C++ is much older than any of those technologies.


You have a highly amusing view of the future.

#5079863 Data Driven Design: Questions (and Answers?)

Posted by Josh Petrie on 23 July 2013 - 09:23 AM

When I learned about Object Oriented Design for my first courses in Java, I sat down and read a book about Java for about 5 months. Then it finally clicked and all the theory I had read over time about how OOD works, suddenly made sense and I could pretty much utilize it all from the get got. It was the same concept I wanted to apply to learning Data Driven Design.



The thing is that despite a similarity in names, object-oriented design and data-driven design are different classes of concept entirely. The former is more structured an idea than the latter. I'd also challenge your assertions regarding your understanding of OO at that point in time, because many academic programs focus entirely on the wrong parts of OO and without using it extensively on real software, you don't really build up a true, "battle tested" understanding. One can acquire a passable understanding of a concept through books and other references, but until you really start using things in practice you have no idea how much you don't know you don't know.


I just really hate the notion of starting to code something and have no one by my side to consult with over it. Which is why I like getting taught by teachers rather than reading books or courses on the internet. If I make things wrong from the get-go and learn nothing I feel I've wasted my time.


You really need to disabuse yourself of this notion. Making mistakes is a critical part of learning and if you try to avoid it, you're only holding yourself back. Build games, and when you have questions or get stuck, you can ask people on the internet. Stop being afraid of doing it wrong. Everybody has, everybody will continue to do it wrong and make mistakes -- professional engineers who have been building games for ten years still make them happily.


You are holding yourself back by not trying to train yourself out of that pattern.

#5079854 Data Driven Design: Questions (and Answers?)

Posted by Josh Petrie on 23 July 2013 - 08:54 AM

As I said on GDSE, you are massively overcomplicating things. Data-driven design just means you keep your code and your data separate, and you allow the code to be directed by the data instead of the other way around. Simple things like loading configuration information from text files put you on the path to data-driven design.


Your problem appears to be that you are suffering from design paralysis because you're trying to take in the entire scope of everything that could be considered data-driven design at all once, including complete existing implementations, so you can rebuild it yourself. This is bound to result in frustration and failure. You need to start small, and build systems that you need for your games. Reading other people's code can be interesting, but often lacking in a lot of critical detail about the why of various decisions that can easily lead you astray.


Your dream goal is to have an engine on-par with AAA titles. That's great, but the way you're going to get there is not to explore a bunch of code other people have written that leverage data-driven techniques. You're going to get there by writing games. Don't worry about "making the engine very abstract so you can write many different games on it" to start with. You will evolve your code there eventually: for now, focus on smaller goals.


Pretty much the only piece of technology you need in place to start with is a way to actually load structured data from files. You can find great third-party libraries for parsing XML or JSON. For example, I use picojson often in C++. You may optionally want to have a serialization layer that uses the external library to turn data files into C++ structures, but for small projects I would not necessarily build that layer to start with. Wait until you have unburdened yourself of this design paralysis that plagues you right now.


Every time you build a new gameplay feature, take note of the inputs to that feature that control how it behave. Consider what is gating every conditional statement and while loop in that feature's code, and ask yourself "does it make sense that I'd want to tweak or change this?" If the answer is yes, consider how to put it into data.


Focus entirely on that concept for now, and finish a single simple game with it. Then, as you move on to another game, take stock of your existing code and see what is immediately re-usable, and what might be re-usable with some refactoring. Start to build that second game, and refactor the components you need as you need to increase their generality. Additionally, with your next project, pick a new aspect of technology to focus on. First you essentially focused on "loading data from files," so perhaps your second project would be the right time to start adding a more powerful serialization layer between the data and the code (so you're not just passing around XML node pointers or JSON objects into your feature code). Or, perhaps it's time to look into how you could implement a system that automatically reloaded data as it was changed.


By refining your code through projects with limited scope and concrete goals (a simple game), focusing each time on a small set of technology improvements, you will find yourself well on your way to having a reusable engine codebase. If you try to get there mainly by studying other people's code and one day sitting down and building the bulk of your final goal... you'll almost certainly fail.

#5079644 My friend and is c# book...

Posted by Josh Petrie on 22 July 2013 - 01:21 PM

He doesn't seem to want your help or advice, so I'd suggest that you leave him alone to waste his own time if he so choses.

#5071489 How on earth do I start a game?!

Posted by Josh Petrie on 20 June 2013 - 10:03 AM

I've got step-by-step instructions on how to create games on my website www.MarekKnows.com.  


You'll want to start simple by first figuring out how to render an image on the screen.  Then figure out how to move it, and then add some game logic.  Start simple with something like Pong and work your way up.

Which seem to be behind some kind of complicated paywall / download credit system? This post reads too much like an advertisement for my taste.  Please refrain from such content-free posts in the future.

#5070438 KeyDown Event won't fire; KeyPreview is True

Posted by Josh Petrie on 17 June 2013 - 09:17 AM

I would like to avoid using Windows Forms Designer; I would prefer to learn how to write it properly myself.



There's nothing "improper" about using the forms designer; it's there for a reason, and it can be an incredibly useful time-saving tool. There are places where it's not a great idea to use it, and that's fine (this probably isn't one of those places), but when you do avoid it you don't have to replicate the code it generates like you appear to have done. It's not usually necessary. In this case you've severely over-complicated things.


Try this:

  • Make a new C# Windows Forms application.
  • Add a new UserControl.
  • In that UserControl's constructor, subscribe to the KeyDown event: KeyDown += MyEventHandler (and implement MyEventHandler).
  • In the default form created for you by the application template, drag and drop an instance of your user control from the toolbox to the form.
  • Run your application, press a key.

In the default VS 2012 template, this should work fine. You don't need to muck about with your own form subclass, or with storing a static instance of that form within your user control (in fact that's a terrible idea). You're doing a fair bit of really weird / bad things in that code you've posted; I didn't go through all of it but that's probably the reason your events aren't firing correctly. You don't even appear to be calling Application.Run so your Windows event pump probably isn't running correctly.

#5056074 Starting without wanting to find a job

Posted by Josh Petrie on 23 April 2013 - 08:55 AM

I think you would be making a poor career and life choice if you didn't finish school.


The answer to your question depends on what you define "successful" as. It is certainly possible to develop and release a game on your own time purely utilizing your own ideas and skills. However, the chance of that release becoming commercial success of the order required to serve as a replacement for full-time employment is smaller. It depends both on some measure of chance and some non-trivial measure of the skills you have in the realm of marketing and publicizing your game. If you go this route and the end result is a commercial flop, as is the case with most indie games, you'll find yourself in the potentially awkward position of having a subpar education relative your peers who you may now be competing in the job market against, simply because you need to do something to bring in sufficient sustained income to pay your rent.


There's no reason you should be gathering a team to help you on this game project at this point, you're only just learning the basic skills you'll need to put your game together. You can achieve a huge percentage of the work of making this game on your own, so bringing in other people will only complicate the process for you. Remove that complication and use the extra time it gives you to stay in school. Your future self will probably thank you.


Almost everybody who is technically inclined and/or intelligent has a tendency to develop the notion, at one point during their education, that they don't need school. That they're smart enough already. Most of the time those people are wrong, and the sooner they can be disabused of this notion, the better things will turn out for them in the long run. It sounds like you're going through that phase and you need to work through it -- it's unpleasant, I realize, but you should look for ways to work through the problems and boredom you are facing.


The paper that you linked, for example, is not impressive in any capacity. It's really little more than a large glossary of terms and the definitions you apply to those terms are in some cases wrong and in some cases clearly reflect your own youth and inexperience. It would make a very poor technical reference for anything.


If you're only learning C++ now you have a ways to go before you can really start building a game of any note -- especially since C++ is a very poor choice of first language (and if you already know another language, you could be using that instead to start building games now). Stay in school and work on putting together some games in your spare time. In a few years you'll actually have some games that might be a bit fun and are capable of demonstrating something more than basic core competencies in game development, and not only will that help you along your goal of making this non-player-centric game, but will put you well ahead of many hopeful game developers who will be finishing school and applying for jobs with no games or projects under their belt whatsoever beyond the stuff they were required to do for school.

#5047993 Which is easier to program C# or Java?

Posted by Josh Petrie on 29 March 2013 - 08:56 AM

This isn't a worthwhile discussion -- "easier" is highly subjective, and there's more to it than the language itself (for example, the toolchains are a huge factor). Try both and see which you find more appealing.

#5017530 What kind of optimization makes C++ faster than C#?

Posted by Josh Petrie on 04 January 2013 - 04:34 PM

This is way off-topic for this forum now.

#5008844 First complete C++ program (simple)

Posted by Josh Petrie on 09 December 2012 - 12:56 PM

In addition to the above, consider next learning about structures and aggregate data storage and create a structure representing a question and answer (or answer). This will vastly reduce the amount of repetition in your code.

Following that, learn about file IO and put your questions and answers in text files, then load them at runtime.

#5001282 --- Finished Breakout ---

Posted by Josh Petrie on 15 November 2012 - 11:12 AM

There are two basic ideas that I'm trying to drive you towards: the idea that a given class or interface should serve a single function ("single responsibility principle") and, to that end, the idea that while object-oriented design begins with the conceptualization of types as real world analogues, it doesn't (and shouldn't end there) -- you can have classes that don't correspond to real-world objects.

Your sprite manager code has some game-specific constructs, such as a specific texture variable for the player and the ball. It also handles game-specific initialization and update logic, such as StartGame and the collision checks (even the fact that it handles collision at all is problematic).

At a high level, I would instead expect to see this:
  • A type called "SpriteManager" should only understand how to manage a list of (generic) sprite objects and send them to the graphics card at render time. While these sprites may include position, width and height as data, that data is not necessarily what is used to perform collision. The idea that collision geometry and render geometry are distinct is a common practice and becomes very important with 3D games or even in 2D games when you have complicated shapes.
  • You should have a distinct entity for representing collision geometry; perhaps a "CollisionShape" interface contains collision bounds information. These collision entities should be managed by a "CollisionWorld" or similar high-level interface that understands the relative positions of all collision entities and can raise events or invoke callbacks when any set of entities enters or leaves collision (or remains in collision across more than one frame, that can be useful as well).

Your top-level "game" class should be the one that contains all the game specific logic and types. The game class can maintain a set of logical game objects -- either using a single common class or, if their functionality differs wildly enough, many classes. Since we're already attempting to generalize quite a lot, I will leave further generalization of the game logic entities to you and, for the purposes of this example, say we have a Ball class and a Player class.

The game creates a ball instance, and asks the sprite manager to create a corresponding sprite. That sprite is stored in the ball object. Similarly, the game asks the collision world to construct a collision entity with the ball's dimensions and initial position in the world. A reference to that entity is also stored in the ball. Similarly for the player.

Now the game loop consists of, approximately: collecting player input, applying those inputs to the player object's collision entity (to move it), then asking the collision world to update. This will cause the collision world to fire any callbacks registered concerning inter-object collision -- the game would have installed a callback to handle ball-ball collision, ball-wall collision, and ball-player collision, possibly. In those callbacks, appropriate action can be taken by the game class -- perhaps to destroy one or both entities, or reflect the path of one to cause a "bounce" effect, et cetera.

Finally, the game looks at every game entity it knows about (balls, player, et cetera) and transfers the appropriate logical properties -- such as position, or damage state, or whatever -- to the object's renderable representation (the sprite in this case). Then your game asks the sprite manager to render all your frames.

With only this first level of generalization and refactoring (and there's much more you can do on top of this), you should have two systems -- the collision handling stuff and the sprite handling stuff -- that are entirely game-agnostic and can be reused and extended without having to couple them to the idea of a breakout (or any other) kind of game. It's only at the highest level of abstraction where your game-specific logic and means of tying these two systems together exist.