Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

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!


darkhaven3

Member Since 14 Dec 2012
Offline Last Active Mar 13 2013 09:32 PM

#5012637 What language should I write my indie game in?

Posted by darkhaven3 on 19 December 2012 - 05:48 PM

If you know Java, stick with that! If you're SPECIFICALLY trying to learn a new language, try out C or C++.


#5012540 engine design

Posted by darkhaven3 on 19 December 2012 - 12:43 PM

I need to comment on this though. I feel like you've used the word "we" as if everyone is as experienced as you in writing software. Not everyone understands the concepts of these core engine features - nor does every game even require some of the features you've listed above.


Then maybe that individual shouldn't be writing their own game engine just yet. It is common knowledge that a good game in this modern era generally requires that there be a standard format or formats for images in place that you will read from the disk, audio of some form, and some kind of user interface. I believe all of these can be cleanly separated into core components of a game engine, and you don't have to be the most intelligent person in the world or even a programmer at all to understand these requirements.

How does one even implement 'camera panning' without some concrete requirement of how it's going to be used? I'll usually fall into the "what if the end-user wants to do this or that" trap... and will ultimately end up writing a bunch of code that never gets used. Personally, I'd rather write a feature for a requirement of the game, instead of some generic feature. And then, if I notice this may be a nice chunk of code to use again, factor it out.


This implies that the programmer has no idea what kind of game he will be programming, or will be somehow working on-the-fly without some kind of design document about how the game should be implemented written down first. If you are writing a text adventure, you know you will not need camera control of any kind. If you are writing some kind of 2D or 3D game, you will certainly need some kind of "camera" in as abstract of a sense as I can put it. Don't need a particular camera feature for your game? #ifdef it out in your game header files or something.

Writing software without concrete requirements can be very difficult, which is why I believe writing engines can be so difficult. Writing a game/demo/unit test is so much easier because those applications inherently come with a set of requirements which have purpose, and can help keep a programmer focused.


If you don't have a game design document that clearly outlines the scope and format of the game before you start writing code, I believe you have more serious issues to attend to than deciding how to write your engine. These are all issues that seem easily resolved at the planning stage; if I'm writing a game for Gameboy Advance, I can have it on good faith I'm not going to be needing things like vertex coloring and DX11 tesselation. Likewise, if I'm writing a game on PC and I want it to look fancy, I can implement these features and I will know that I will need to have this information stored in some kind of consistent format.

In short, while I respect that you might find it difficult to write a game engine, it feels like you are assuming that everyone just writes game engines without some kind of idea as to what kind of game the engine will be used for.


#5012534 Once you go OO, you never go back?

Posted by darkhaven3 on 19 December 2012 - 12:30 PM

this will become tragically clear once you'll try to debug a big project where everything can talk and modify everything else.. at that point it becomes really hard to figure out what's going on... this, again, has nothing to do with OOP but more to do with global state and basic programming theory.
Of course, from a programmer's point of view, being able to access every function and every variable feels like a good thing, but it quickly turns into a total mess... and the problem gets bigger as the software gets bigger, so you might get away with it with small code bases.

I think I can safely say that the above is pretty much a nonexistent issue. In C, you cannot "access every function and every variable"; a static int declared within a function remains within the scope of that function, and cannot be overwritten directly. Of course, it's quite possible to do so intentionally, in the same way that it is with any OOP language that doesn't do bounds checking on arrays, if you get where I'm going with that.

If I don't want a function to modify something, I'll pass it a pointer-to-const (i.e. const int* var; ). If I want a variable to be available locally to a function, I will initialize that variable within the function that requires it. Not much more to it than that, honestly. If it comes to a point where data is being modified that I didn't intend to be modified, I can always have a look at that nifty map file the linker generates, which is available to both C and C++ programs.


#5012486 Once you go OO, you never go back?

Posted by darkhaven3 on 19 December 2012 - 10:47 AM

After being a C++ programmer for a little while and dabbling with Java, I have to say that in my opinion object-oriented programming is relatively worthless to me. I honestly don't see why I should ever bother worrying about whether or not a particular set of functions can "see" each other, or whether or not I can make two functions with the same name. Why would I ever want more code obfuscation like that -- two functions with identical names that can do two completely different operations? Why on earth would I ever want such a thing?

But this is of course only my opinion. I'm not unique in the way I think, surely, but I'm also probably not at all a rare, dying species of programmer.

A recent example that I can think of is the IW engine (used in every single major Call of Duty title). It's based directly on the Quake 3 source, so I can imagine it's probably in C still.


#5012410 engine design

Posted by darkhaven3 on 19 December 2012 - 06:00 AM

Continue writing games. Then look back and factor out any common and reusable code. This will serve as the basis of your engine.


I'd much rather think of the "showcase game" of my technology as a way to shape the engine I've written for it. I would rather start with an engine that's broad in scope and use my first game with it as a way to iron out bugs in the engine, discover weak points in my engine code, and streamline the parts of the engine code that need it most so that when I make a game in the future, I have a solid tech to start with that I know will work and I don't have to remove a bunch of extraneous hacks that I had to use to force my previous game to even function.


#5012188 Tile based RPG

Posted by darkhaven3 on 18 December 2012 - 02:15 PM

I acknowledge that I'm getting way too pushy on this subject. Carry on.


#5011983 How to distribute a game without being accused of distributing a virus.

Posted by darkhaven3 on 18 December 2012 - 04:51 AM

He's probably getting that message just because of the fact that his browser is seeing an executable, regardless of its contents. The best way to ensure that you're not going to be accused of distributing a virus is not to change your language or anything of that nature.

It might not be the best way, but it's at least probably good practice to have the MD5 checksum of the file you're distributing readily available to be checked against an MD5 tool's output so that there is no confusion as to whether a third party is tampering with your file. Even better if you have the sourcecode available so that particularly skeptical users are free to compile it on their own if they wish.


#5011968 Tile based RPG

Posted by darkhaven3 on 18 December 2012 - 03:23 AM

Just use plain C. Can't go wrong. You can draw on the experience you already have with C++ without having to worry about writing generic code, code generation, templates or classes and private and public stuff. More often than not, libraries that are out for C++ probably have vanilla C bindings (I know for sure SFML has this -- CSFML -- and SFML seems to be very good for writing games with).

In other words, try out plain C before trying to write a full game in C++. I feel like there's less obfuscation involved in C, and you can just get down to the meat of the code more easily than in C++. While C++ is by no means unreadable or unusable in my eyes, it feels... less so than C for projects that take advantage of the features C++ has to offer.


#5011228 program performance

Posted by darkhaven3 on 16 December 2012 - 05:11 AM

Honestly in my opinion you should never sacrifice performance for conforming to some standard. Try everything. If you find that you gain a bunch of cycles in a critical piece of code by messing with how your variables are accessed, then by all means, that is the correct thing you should be doing, regardless of what standard you are now failing to conform to.

It really depends on who's going to end up reading your code or who will be using it, though. If you're virtually the only one that's going to be looking at your renderer code, for example, then by all means document what you're doing and mangle the code into oblivion if it performs fast as hell.

As PAndersson stated, though, it shouldn't be the first thing you aim for. You should start with something simple that you know will get you the correct results first, and then worry about turning your code into a nebulous mindsink later.


#5010902 need help

Posted by darkhaven3 on 15 December 2012 - 04:37 AM

An important thing I think needs to be said is that you're not necessarily programming different versions of your renderer code specific to different GPU hardware manufacturers if you're writing OpenGL or DirectX code. The practice of writing as close to the metal as possible to achieve good results has kind of gone to the wayside for PC game development since the days of GLQuake and is more or less delegated almost entirely to fixed platforms such as game consoles. That's not to say you couldn't just go ahead and write different versions of your code for say, the GeForce 600 series, the 500 series, and then a version specific to the Radeon 6xxx series, but it will probably end up being more frustrating and more effort than it's worth than to just write for OpenGL or DirectX.

What's ultimately happening is that you're calling to OpenGL, which then interacts with your video card drivers, which then finally interacts with your graphics card.

Really, I think the most important choice you're going to end up making as far as target hardware is concerned is whether or not to write in OGL or DirectX if it's for a PC game.


PARTNERS