Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 18 Oct 2007
Offline Last Active Jun 28 2014 06:45 PM

Posts I've Made

In Topic: What to do now?

14 June 2014 - 01:36 AM

What advice would you like to give me?

Set realistic goals.

It sounds like you're either getting frustrated or just tired of working on the same project. Spending 5 months just getting rendering working is a little strange to be honest, unless you've been working at it VERY rarely.

What I would do:

-Decide if you're fine with adding a lot more code to your game, if you are, then sit down and figure out what your goals are with your game. If you're having trouble deciding what to work on then do the "what would I play" test, think about the order of things you can add to your game that will make it fun to play around with. Is the game going to have enemies to shoot? Well networking is probably second of importance then if you can't even shoot enemies or be killed yet. Is it all networked and only PVP? Networking is probably a higher priority then so you can start testing the actual mechanics.

-If you feel like you're gonna snap if you keep working on your game for much longer, then sit down and think how you could round the game off. You could probably do without sound for example, or some very basic sound, focus on adding the few features to the game to make it more like a game. If anything the worst part of putting months of work into a project is the temptation to just abandon it, at least make it so when you pop it open again in the future it acts like a game.

Personally I would focus on making the shooting game have actual shooting and defeating enemies before the other stuff, add stuff either in gameplay order or in the order that most interests you if you're working by yourself.

In Topic: Python/Java options for learning networking?

14 June 2014 - 01:25 AM

Yeah, don't make games in C.

If you're going to go that route at least learn C++, C is only really useful for specialty tasks these days like writing OS level code or embedded software(because C compilers are very easy to write.) Anything game related that isn't using a higher level language will be in C++.

Beej's guide is all about basic sockets, you don't HAVE to write with those in order to get networking in a game, there are usually quite a few libraries that abstract away the details for you(C++ has Raknet for example) Java probably has a built in library and a lot of third party ones, same with Python. In fact I probably wouldn't bother dealing with sockets unless you have a good reason to(need to write your own unusual behavior or your goal is to get in depth with network coding.)

In Topic: java or javascript?

11 June 2014 - 06:15 AM

The examples might not be 100% accurate, but my point is that if you know what you're doing, syntax shouldn't be too much of a problem. How long did it take you to see the differences between the two blocks of code? And notice how syntax is consistent across the language, so the differences between a language and another tend to be consistent also.

Not sure why you're even pointing any of this out because the things you pointed out are pretty much generic to all popular languages. A lot of them are concepts that came about from having to work with assembly and don't really say anything about the logic of a language.

Python and C++ might superficially seem similar, but they share as many similarities as cars and cows.

In Topic: (c#) list of lists of lists or outside helpers?

11 June 2014 - 05:59 AM

You shouldn't even be asking about speed unless speed is a problem. At best we can give you vague suggestions, profiling is the only way to get an accurate answer.

What you probably should be asking is "what do I need to do with these items?" Maybe write down a list or ponder it for a bit, "where do I need to access them from?" or "Do I need to be able to search every item in the game for specific ones?" Usage should be the important thing.

In Topic: I hate my code....How do you structure your code for a game?

11 June 2014 - 05:45 AM

Also, there are probably people with that much experience in such an AAA-gamedev-team, that can work with this horrible code just like most other people do with "good" one. Even I notice with growing practice how much easier it gets to read and understand other peoples code, no matter how badly is is written.

Not sure where you get that idea, bad code is harder to read than good code, thats kind of a generic point that relates nothing to how good you are at reading code. It's also not a good excuse. That's like saying you serve worse and worse food in your restraunt because the customers have progressively gotten used to bad taste. Your teammates are customers to your code, they're the ones that have to swallow it when they work with it.

Also, in such an AAA-environement, probably most of the code in the end is hidden under some toolset, using an editor & scripting/visual scripting, so its not that bad.

Not sure where this one comes from either, plenty of companies still code their own engines, even those using stuff like Unreal will still end up having to write a bunch of code generally, there will be plenty of programmers out there dealing with code that isn't hidden under a fascade of a tool.

I just feel that just "getting things to work" is, depending on the aims of the OP a little waste of time. He isn't part of any company and doesn't have any restrictions. Why not spend a little time getting to know how to create better code?

Because it isn't a little code, proper programming practices are often a lot of learning and practice and hard calls to make without having written the same kind of "thing" a hundred times before. A lot of people(including myself) got a lot of spiel from places like here where everyone was basically going "No you have to do it THIS way, otherwise it sucks." It stuck, many a time I sat there staring at code thinking "I know this is wrong, but how do I fix it?" Days and weeks and months of wasted time trying to be 'correct' when in reality I should have just been putting code to keyboard.

If anything there should be a rule that whenever you code something new, the first two or three times you make a similar thing, you forget all coding good practices and just make the code work, see what it actually does and what it needs and ignore generic advice.

I always try to view the cost/gain of things. If I spend an afternoon thinking about and refactoring my game object system, so that creating a new game object takes significantely less time, is less prone to error and thereby saves time spent on debugging strange errors, and also increases readability, why not?

Except I would bet money that you spend much more than an afternoon on it, if you work on a game for a month you might spend days of time just worrying about refactoring. If I had to be logically accurate the only real way that better code is ever worth more money is when it saves more effort in the future.

Everything past that is just being nice for the coder, and although I'm a stickler for pretty code, the reality is that you're going to be working with a lot of slobs or people being rushed to get things put together, so its worth learning how to deal with it and not just be used to everything being neat and perfect.

Why should a beginner, that just codes for a hobby, really try to "sh*t" code/features out as fast as he can?

Because it is one of the only feasible ways you can learn. For instance people on these forums often demonize the concept of a singleton or any kind of global managers. Problem is those things usually simplify code, they simplify it enough to where a lot of developers use them religiously for things like engine subsystems. For a beginner or just for a small project they are probably time savers more than anything else, but I was taught to avoid them like the plague.

If anything that just points out that "there is no golden rules in programming" should apply to best practice advice as well.