Jump to content

  • Log In with Google      Sign In   
  • Create Account

speciesUnknown

Member Since 08 Oct 2006
Offline Last Active Nov 20 2012 04:52 PM

#4860532 How to Log and stay Modular

Posted by speciesUnknown on 11 September 2011 - 08:49 PM

The OP could have written a logging system many times over in the time this thread has taken. I think we have run into the bikeshed principle here.

OP: Use free functions. Forget modularity. Then get on with the real work, of which actual logging is probably a tiny fraction.


#4859995 Is it bad to use OOP?

Posted by speciesUnknown on 10 September 2011 - 08:27 AM

Use an object pool full of value types, with a swap/remove semantic, and punch anybody in the face who tries to make you change to a microallocation system. You don't need to start out with a pool of 10k objects slots, you can make it smaller, and reallocate to size*2 every time you run out, then do a full copy. This won't be taking place on every single frame.

I wasn't joking about punching them in the face.

If you have 10k transient objects you need to pool, or else your memory will be scattered all over the shop, there is no two ways about it.

There is an important thing to understand - OOP does not imply classes, interfaces, operator new, inheritance, polymorphism... Those are implementations of OOP. You can still call a design which is based around objects being instanced, even if no other canonical OOP language features are used, as OOP. Just in case you need to beat back some academics at some point.


#4859092 How to Log and stay Modular

Posted by speciesUnknown on 08 September 2011 - 10:17 AM



I agree with the general sentiment that you are over-engineering, or that you are forcibly applying the principle of EVERYTHING MUST BE AN OBJECT which you may have picked up at college / uni. OOP is a methodology of programming, not an ideology.

When it comes to logging, you have a finite number of options.

1) Create a new logger and then throw it away every time you want to log something
2) have a single global logger. (no, I didn't say singleton, I said single global instance, the terms are not synonymous)
3) use a free function, or depending on the language, a static function.
4) pass a logger to every single constructor of every single object your game uses.

It should be obvious from these choices what the correct course of action is. Let the academics continue to think inside their little boxes up there in that ivory tower while you like, get some work done.


Option 4 with IoC wiring app/domain services is best.



Okay, I will talk with my team and see how we can implement that.

BTW thank you to everyone for all your wonderful answers. Even if I don't quote them, it doesn't mean I didn't learn a lot from them.

-Brent


Holy shit man, option 4 was supposed to be an obviously wrong answer, and return0's addition was a joke O_o please tell me that from all this you didn't learn that the best solution was the most complicated and intrusive one?


#4857165 Learning graphics programming, not just an API

Posted by speciesUnknown on 03 September 2011 - 09:06 AM

I've done a fair bit of both Direct3D (through XNA) and OpenGL graphics programming. It's never been very complex code, just the bare minimum I've needed for my game projects. However, graphics programming is something that's always interested me (it's kind of the reason I got into programming in the first place), and now I'm looking to really dive into computer graphics to see if it's as interesting as I think it is (if that makes any sense).

I searched on these forums and some people suggested writing a raytracer or a software renderer to really understand the basics properly, but I don't really know where to start with either. I've looked at some of the literature, and it seems like most of the recommended books are very theory oriented, which seems like a bad way for a relative newbie to get into it. Maybe that's just the nature of graphics programming, I don't know. I'm not looking for a book that just teaches me an API, but more for something that with some work can give me enough of the ideas behind computer graphics that I might be able to move on to things like raytracing or software rendering. Any suggestions?


It used to be the case that you would learn to use a graphics API, but shaders changed all that. Now, you learn a technique, and then implement it in shaders. So, being able to write shaders would be the first step to learning graphics programming. You need to understand the transformation / rasterization process, and writing a software renderer will let you do that, but software renderers are of limited use in real life.


#4857155 How to Log and stay Modular

Posted by speciesUnknown on 03 September 2011 - 08:37 AM

I agree with the general sentiment that you are over-engineering, or that you are forcibly applying the principle of EVERYTHING MUST BE AN OBJECT which you may have picked up at college / uni. OOP is a methodology of programming, not an ideology.

When it comes to logging, you have a finite number of options.

1) Create a new logger and then throw it away every time you want to log something
2) have a single global logger. (no, I didn't say singleton, I said single global instance, the terms are not synonymous)
3) use a free function, or depending on the language, a static function.
4) pass a logger to every single constructor of every single object your game uses.

It should be obvious from these choices what the correct course of action is. Let the academics continue to think inside their little boxes up there in that ivory tower while you like, get some work done.


#4857149 FPS "Accuracy" value that affects the size of your crosshair

Posted by speciesUnknown on 03 September 2011 - 08:24 AM

Rather than approaching accuracy this way, why not approach it from the user's perspective? To the user, the "accuracy" of the weapon equates to how far away from an enemy they can be for all rounds aimed at the target to hit a part of the target. Weapons have a cone of fire within this accuracy range. So, if I aim perfectly at the center of the torso of a guard standing 100m away, a weapon which will ensure that every round I fire will hit the guy's torso is accurate to 100m.

If your game has a headshot mechanic, then you could instead use the head of the average target as the accuracy figure, so, a weapon accurate to 100m means that up to 100m away, any shot aimed perfectly(i.e. without user error) at the centre of a target's head will hit its head.

You could use "Minute of arc" as your input accuracy value, which is what rifle manufacturers use to measure their accuracy, http://en.wikipedia....of_arc#Firearms

This is far better than a value which has mathematical meaning to the programmer but is totally meaningless to the player, and which will force you to use trial and error while balancing the accuracy of your game's weapons. What you then do is add to this value (high values are worse) if the player is moving, subtract from it if they are crouched, etc.

[edit]
sorry, i misunderstood the intent of the OP. However, my answer to this is simple - make the gap in the crosshairs range between 0 MoA (crosshair is totally closed) and an arbitrary value somewhere in the high MoA's (say, 10 MoA) and use your current calculated MoA to interpolate between these two positions.


#4854585 Self set Challenge: 2 month dev cycle

Posted by speciesUnknown on 27 August 2011 - 05:16 PM

so basically you didnt work on your game at all :wink:, what you listed were mainly parts of the engine, thats the reason why you didnt finish it, hell you were only perhaps 10% of the way in, if that. Im not rying to sound mean but just realistic.
By coincidence I finished a game yesterday, Ive just gotta name it & upload it to googles web store site.

Mate no doubt youve heard the saying work on the game and not the engine, .... well, its true.
Next time try this (and I cant emphasize this enuf) get it playable on day 1.
Trust me, you do this & you will have a game finished in 2 months



I think that the game idea I was trying to implement is of sufficient complexity that i really needed a lot of backing framework - call it engine, API, framework or whatever. The point is, there was a lot more basic ground work required than I had anticipated. I havn't been trying to implement an engine for the sake of the engine, everything I have implemented has been in some way targeted at the game itself, so the old adage "write games not engines" is not relevant here. The game was a 3d vehicle combat game with semi-realistic physics and a stylised renderer - and at the same time, i was trying to implement a theory I've long had about a combination of DoD and component based models.

Anyway, I'm in the process of wrapping up the game functionality to something playable so I can look at more realistic goals, either in terms of time frame or game complexity. Its not been a total loss.


#4854536 So what do you think of this DRM scheme?

Posted by speciesUnknown on 27 August 2011 - 02:06 PM

Crossing the boundary between the game itself and the user's computer in general is a bad idea. Destroying the game itself will not evoke any pity on behalf of the user, because nobody will consider that they have any right to whatever they managed to get for free. However, if you destroy something outside of the game, you will open a whole can of worms.

I am all for the idea of detecting a pirate copy and stopping the game from running, but anything which involves taking revenge turns you into the bad guy, because this moves the debate from one of deterrence, to one of revenge.


#4847947 Fighter Jet HUD

Posted by speciesUnknown on 11 August 2011 - 03:51 PM

Calculating the horizon: I think the best solution here would be the cross product of a world space Up vector and the facing vector of the craft.

As for the behaviour of the middle point, it seems to be always pointing towards the launch vector, relative to the craft, of the weapons. I.E. if the pilot fires the machineguns, the rounds will approximately end up in the circular area. When the craft is in an upward or downward loop, it makes sense that the target point would not be visible to the pilot, which is why it goes off display at this point. I imagine that the reticle can be set for different ranges, which will affect how far off display it will be for a given banking velocity.

Just remember, you should be implementing some middle point between what is realistic and what is most fun - to make sure you get the right balance beween flight simulator anoraks and frat boy 360 gamers :P If its not totally realistic, thats not a disaster.

Disclaimer: I don't know all the correct aviation terms. Don't laugh at me.


#4844808 Remember 'tighten up the graphics' ?

Posted by speciesUnknown on 04 August 2011 - 07:09 PM


America's Army 3.

ctrl-f, "amber"

She must be really upset for not being credited...


that lieing f'ing s!ut....... lol that just makes the video even funnier in my eyes


she's an actress (porn star?) not a liar, but calling her a slut is not appropriate. Unless she is a porn star, in which case she wont be offended anyway.

Not that I'd know anything about that.


#4844782 unlimited detail back again

Posted by speciesUnknown on 04 August 2011 - 05:35 PM

This whole thing reminds me of perpetual motion charlatans.

Most of them go for years believing that they are "just around the corner" from pushing past 1.0 efficiency and being able to generate power from nowhere. What actually happens is that they push closer and closer to 1.0 but never surpass it. When questioned about why they are not making millions, they talk about how supposedly, The Big Corporations are trying their utmost to hold them back, blaming their lack of pushing past the 1.0 mark on the lack of investment, calling it a conspiracy.

In reality of course, they are getting investment from places unaffiliated with The Big Corporations, but they keep each investor at arms length, and avoid investors who would invest enough to want to know why its not enough. They explain this to the small investors by saying the large investors are all affiliated with The Big Corporations. There are massive flaws with the concept of perpetual motion as a source of energy, but in all their material they gloss over these issues, because they want to attract small investors.



Meanwhile, ordinary people who don't understand the various technologies involved see it as just that - a little guy is trying to push some new paradigm which would work if only The Big Corporations would help them with proper investment and technology. They believe the line that The Big Corporations are all conspiring to prevent the disruptive new technology from advancing to commercial applications.

I suspect that the current state of their business is banging their heads against a brick wall, trying to solve a few major issues (which may be unsolvable with current tech) to release their SDK. The only way we will ever know if they can be taken seriously is if they release this SDK and it works. Until that point, they are in interesting concept with no flesh on it.


#4844737 visual studio 2010 worth it?

Posted by speciesUnknown on 04 August 2011 - 04:11 PM

Lets look at the new features.

c++ intellisense is better.
Incremental update in supported .net versions.

Is that it? I seem to have missed a few things here.

So really, from my perspective, all vs2010 does is use more memory (it struggles on my 2gb laptop, with bits of it constantly getting paged out. I spend no end of time waiting for it while it hangs) and support the newer compiler versions? The reason 2010 exists is that they wanted to escape from the winforms / win32 nightmare that was the previous code base. They've not really added a whole lot of newer features. Going from 2k8 professional to 2010 express is a massive downgrade in features; so, if upgrading means moving from pro to express, don't bother.


[edit] oh yeah, i missed the new multimonitor support, although im not sure express has that, so again, going from 2k8 professional to 2010 express is a downgrade.


#4843636 Basic game structure?

Posted by speciesUnknown on 02 August 2011 - 09:31 AM


This will teach you how to use SDL but it wont teach you to structure a game - this is something totally indendent of what API's you are using.


It's SDL based but the object oriented structure of the engine seemed valid to me. Check out the sample of what you end up with: Sample Perhaps this is where I'm going wrong :P Thanks.


It demonstrates some of the basics, but lacks some important things. Its implementation of actual game structure is very very simple, so that it doesnt get in the way of the SDL side of things. Just as a brief

No game state management - how are you supposed to have an in-game menu or a loading screen or anything else like that?


Draw code is the most primitive - no sorting or culling of any kind - just a brute force iteration like I mentioned before.


Its actual c++ code is somewhat shitty, for example, it stores a global array of all entities and provides no API for accessing them safely, you have direct access. This is indicative of the fact that its not teaching you engine design, its teaching you SDL, and so the "engine" is the simplest possible implementation of an engine.

It's not really object oriented, its more procedural (this is OK as a practice, I'm just pointing it out since you said "object oriented structure of the engine". I often use procedural constructs for more high level application structure and objects for things which are.. well, objects).

It uses defines instead of constants for global constants. (const members are preferred in real life for reasons of type safety and various more complicated reasons, but would turn this into more of a c++ tutorial, which is not the aim - its an SDL tutorial)

In short, it should be used as a tutorial for SDL, not a tutorial for game structure in general. And for god's sake don't use it as a tutorial for c++.

I would like to emphasize what I previously said: tutorials like this help you learn to use an API but they aren't oriented around teaching you the more abstract disciplines of game structure in general, and you should regard any background structure of an engine they create as being solely intended to support the API specific principles.


#4843614 Basic game structure?

Posted by speciesUnknown on 02 August 2011 - 08:26 AM


Hi all. I'm new here.Posted Image I'm currently learning SDL and OpenGL so i can make games but i'm not sure about the structure of the code. It's the basic struture of how it all works and goes together that i'm not quite getting. I know how to design the basic layout of a game but it's the actual code that i'm not sure on. I've searched for help on this but i couldn't find what i was looking for so i thought i'd ask here for some advice from the experts. Thanks.


Hi. I'm not an expert but I found the tutorials over at SDL Tutorials to be very helpful. By the end of the tutorials you have a functional (albeit basic) game engine in SDL with C++. There's also a tutorial on using OpenGL with SDL.


This will teach you how to use SDL but it wont teach you to structure a game - this is something totally indendent of what API's you are using.

I recommend you start out by implementing a game state system - this can be as simple as an enum and a switch statement in each of your update and draw functions. When it gets complicated, use this as a controller, and delegate to instances of a class with an update and draw method in them.

You also need to learn how to build a world, into which you can add and remove entities. A simple way to do this is just a class with a dictionary of entities and an add and remove function. Give each entity a unique ID (e.g. by using an integer which you increment each time a new ID is required) and use this to add / remove entities from a dictionary. When you update, you then simply iterate through the dictionary and update every entity.

When you come to draw things, a simple way to do this is to give each entity in the world a draw function, and then brute-force iterate over all entities and call their draw function. A more advanced technique is to test each one against the view to see if it is visible and ignore it if not. An even more advanced method involves adding them to a list, sorted by what texture they use, and then draw them in batches.


#4843599 Predictions: Origin vs Steam

Posted by speciesUnknown on 02 August 2011 - 07:53 AM

An important thing to understand, which I learned a long time ago, is that one cannot pay any attention to marketing bullshit coming out of corporations, or anything in the press derived solely from marketing. This is because marketing by its very nature is playing tricks on us, and anything in the press derived from that tricky information will have the further layer of bullshit required to make the story sell.

This entire situation is buried under so much rhetoric and bullshit that it is impossible to see where it begins and ends.





PARTNERS