So you're saying that if you spend a million man hours on game development, the wrapper stuff will take 0.036 seconds?
I mean actually doing the low level stuff that you need to do to make a game engine. It may not be a huge amount of the work, but it's still enough to easily outweigh any of the trivial advantages OpenGL has over Direct3D.
There are quite a few complaints about DotA load times. When you're waiting a couple of minutes for a game to start, you're getting to Commodore 64 levels. Shader compiling isn't the whole story, but it's a significant factor.
On Windows, if you use Visual Studio (which most studios do), DirectX is easier.
The documentation is fully integrated, and you don't need to use a wrapper or the hideous OpenGL extensions mechanism to use any of the remotely modern features. You can use GLEW for the latter but you really shouldn't have to rely on a third party library just to use it.
Uhm.. no. It's fairly similar to OpenGL and is based on the same principles, but certainly not the same. You don't really want the same. You have no need for the level of abstraction OpenGL provides.
The smartphones use OpenGL ES which is actually a different API from OpenGL although it is a variant used fro embedded systems.
When I was working on this sort of thing a few years ago, we were experimenting with a RISC machine with a fairly deep pipeline for shader operations.
It worked pretty well, and wouldn't be surprised if the big boys used a similar idea but optimisation for these is very architecture dependent and can be an NP complete problem. Even register allocation can be quite slow and they'll have to deal with that.
Lack of games is a factor, but the other factor is games just aren't as good. Load times is a factor in this. And while it may not seem important, 20 seconds is a lot! On consoles, load times are a reason to fail compliance testing.
Well, there's no demand for this because there's a relatively convenient alternative. In this case, the alternative is Windows and DirectX. It doesn't really say a lot for Linux if this is what people are doing.
A phone isn't just a cool toy any more. We're pretty dependent on them. It's our way of communicating with people; it contains a lot of data. We spend a lot of time tinkering with it and configuring it to make it just so.
Even if you have backed it up, it's still a; lot of work getting the data back onto the phone. And you'll probably lose something.
Plus it takes time to replace. We are without an essential tool that we assume we'll have, and are no longer able to function well until it's replaced.
True. I was basing my views on something more comparable with a typical machine (or are SSDs considered mid-high end these days?) but since an SSD has both performance and size advantages it makes sense to assume we'll use one.
One of the drawbacks of a desktop PC is that the standard form factor parts take up a lot more space than they need to. An expansion card can only go to a certain place. There's not a lot of choice with the PSU either. Motherboartds - even ITX ones have a minimum size.
Really the only components that actually take up significant space are the hard disk, PSU and the cooling system (for GPU and CPU). Chips themselves are tiny. If you look at the size of these on a competent rig they don't take up that much space.
An inductive charger would help. Keep it by the bedside. I think it would be more acessible to take of your watch and put it on the charger each night.
UI is still a problem. You can only reasonably display a couple of dozen characters. I think even displaying an entire tweet on one screen would be pushing the limits of the technology.
Sure, you can add procedural rooms, but it still requires programming resources for something not relevant to gameplay.
You can drop the graphical detail, but then that's a compromise. It might be better to split up the level into smaller chunks and make it into 2 or more levels. Or perhaps you can't.
And also that many people who think game design is easy don't realise this.
You already realise this. Good for you. You don't need to read the article. If you work in any creative industry, you'll encounter a lot of people who have a "brilliant idea for a game" (or whatever) and are completely unaware of just how much goes into the simplest aspect of design.
I do agree that the writer makes this harder than it is. I guess the point is that it's not as eas as it seems, but the point has been oversold somewhat.
The point is, most people don't realise just how much minutae you have to deal with in game design, and the job isn't as easy as a lot of people who want to work in games seem to think.
Most people think "Hey, wouldn't it be awesome if we ha could blow holes in all the walls and just kick down every door and we have an entire hotel toplay in with hundreds of rooms.
Yes, it would. But there are other things to consider that people don't think about.
Sure, we can do that. What height is the limit for climbing over, and do we need to make climbable items distinguishable from climbable items that are marginally taller? Some objects need a more complex bounding objects so we need to find the resources to handle that. There are decisions to make here.
And now you can't simply pile up some small rocks to block a door, so you need to revisit the decisions you made on how to prevent access to a door.
Not the case for every game ever. Maybe not even a majority
> Can the player open them?
Some way or another, yes.
Do we even want access to every single room? We may want to illustrate that we're in a corridor. It would make no sense to be able to open all the doors and it would requitre a lot of level design time and memory space to have something on the other side of each door.
> Can the player open every door in the game?
Unlikely. Some doors will be locked, if only to remove the expectation that doors are no obstacle.
If no doors are locked then why do we need to remove this this expectation?
> What tells a player a door is locked and will open, as opposed to a door that they will never open?
A locked door conventionally makes a distinctive thud sound when the player tries to open it. If there needs to be an indication that the door will never open, those doors don't make a sound (and typically have artwork indicating that they're not really usable doors.) There may be visual indications of a lock status (keypad, etc, with display, red=locked, green=unlocked) nearby.
This is one solution. Should we have a message saying the door is locked? If so, what message? Should all doors make the same thud? Does that make sense for a metal door? If we go for different thuds, is the inconsistency too jarring? How much space do the thus assets take up? Is a keypad the correct design given the setting of the current level?
> What happens if there are two players? Does it only lock after both players pass through the door?
Depends on the kind of event that you want the player to believe is the cause of the locking.
So which events will cause the door to unlock or lock for both players and which will cause the door to lock or unlock for only one?
> What if the level is REALLY BIG and can't all exist at the same time?
Does a tree make a sound if there is nobody near to hear it?
Yes. Now, how do you propose we deal with the memory issue created here?
> Do all the players need to see the door open at the same time?
Yes, if they can see it and the status of the door is relevant to the game mechanics.
What if the door is only usable by players with a certain key or character type?
> You need to get your doors in by 3pm if you want them on the disk.
What's the question?
It's not a question.
> Do we need to give everyone those doors or can we save them for a pre-order bonus?
Yes.
Sucks for those who didn't pre-order. We're now the subject of an internet hate capaign because our game is broken. Or, we don't get as many pre-orders as we otherwise would have.
Every one of these questions is a decision that has to be made. The decision depends on the type of game, the resoucrces avalable (both in terms of hardware and developers), and all the decisions you'e made already.
And the point is, this is just doors. You have a similar lot of questions for any other item in your game.
Slashdot Mirror
So you're saying that if you spend a million man hours on game development, the wrapper stuff will take 0.036 seconds?
I mean actually doing the low level stuff that you need to do to make a game engine. It may not be a huge amount of the work, but it's still enough to easily outweigh any of the trivial advantages OpenGL has over Direct3D.
There are quite a few complaints about DotA load times. When you're waiting a couple of minutes for a game to start, you're getting to Commodore 64 levels. Shader compiling isn't the whole story, but it's a significant factor.
On Windows, if you use Visual Studio (which most studios do), DirectX is easier.
The documentation is fully integrated, and you don't need to use a wrapper or the hideous OpenGL extensions mechanism to use any of the remotely modern features. You can use GLEW for the latter but you really shouldn't have to rely on a third party library just to use it.
Uhm.. no. It's fairly similar to OpenGL and is based on the same principles, but certainly not the same. You don't really want the same. You have no need for the level of abstraction OpenGL provides.
The smartphones use OpenGL ES which is actually a different API from OpenGL although it is a variant used fro embedded systems.
When I was working on this sort of thing a few years ago, we were experimenting with a RISC machine with a fairly deep pipeline for shader operations.
It worked pretty well, and wouldn't be surprised if the big boys used a similar idea but optimisation for these is very architecture dependent and can be an NP complete problem. Even register allocation can be quite slow and they'll have to deal with that.
Lack of games is a factor, but the other factor is games just aren't as good. Load times is a factor in this. And while it may not seem important, 20 seconds is a lot! On consoles, load times are a reason to fail compliance testing.
Well, there's no demand for this because there's a relatively convenient alternative. In this case, the alternative is Windows and DirectX. It doesn't really say a lot for Linux if this is what people are doing.
I think the argument is that nobody does so for several years.
So instead of losing the advantages for a few days, I should lose the advantages forever?
That's a pretty crappy solution to the problem.
How should I use it? Keep it at home?
A phone isn't just a cool toy any more. We're pretty dependent on them. It's our way of communicating with people; it contains a lot of data. We spend a lot of time tinkering with it and configuring it to make it just so.
Even if you have backed it up, it's still a; lot of work getting the data back onto the phone. And you'll probably lose something.
Plus it takes time to replace. We are without an essential tool that we assume we'll have, and are no longer able to function well until it's replaced.
True, but I think the basic point still applies.
True. I was basing my views on something more comparable with a typical machine (or are SSDs considered mid-high end these days?) but since an SSD has both performance and size advantages it makes sense to assume we'll use one.
One of the drawbacks of a desktop PC is that the standard form factor parts take up a lot more space than they need to. An expansion card can only go to a certain place. There's not a lot of choice with the PSU either. Motherboartds - even ITX ones have a minimum size.
Really the only components that actually take up significant space are the hard disk, PSU and the cooling system (for GPU and CPU). Chips themselves are tiny. If you look at the size of these on a competent rig they don't take up that much space.
An inductive charger would help. Keep it by the bedside. I think it would be more acessible to take of your watch and put it on the charger each night.
UI is still a problem. You can only reasonably display a couple of dozen characters. I think even displaying an entire tweet on one screen would be pushing the limits of the technology.
Sure, you can add procedural rooms, but it still requires programming resources for something not relevant to gameplay.
You can drop the graphical detail, but then that's a compromise. It might be better to split up the level into smaller chunks and make it into 2 or more levels. Or perhaps you can't.
And also that many people who think game design is easy don't realise this.
You already realise this. Good for you. You don't need to read the article. If you work in any creative industry, you'll encounter a lot of people who have a "brilliant idea for a game" (or whatever) and are completely unaware of just how much goes into the simplest aspect of design.
Yes you can. Now, how does the scheduling of the lockpicking minigame fit in with the release schedule and all the other things we need to do?
To visually represent a scenario that typically has lots of doors (a hotel, for example), or as an entrypoint to the location you've just left.
Yes, it's a wall as far as level design and internal game logic is conerned. It's a door as far as visual cues are concerned.
I do agree that the writer makes this harder than it is. I guess the point is that it's not as eas as it seems, but the point has been oversold somewhat.
If you're the game designer, you're the one deciding what the document says.
The point is, most people don't realise just how much minutae you have to deal with in game design, and the job isn't as easy as a lot of people who want to work in games seem to think.
Most people think "Hey, wouldn't it be awesome if we ha could blow holes in all the walls and just kick down every door and we have an entire hotel toplay in with hundreds of rooms.
Yes, it would. But there are other things to consider that people don't think about.
This is sort of the point...
Sure, we can do that. What height is the limit for climbing over, and do we need to make climbable items distinguishable from climbable items that are marginally taller? Some objects need a more complex bounding objects so we need to find the resources to handle that. There are decisions to make here.
And now you can't simply pile up some small rocks to block a door, so you need to revisit the decisions you made on how to prevent access to a door.
Not the case for every game ever. Maybe not even a majority
Do we even want access to every single room? We may want to illustrate that we're in a corridor. It would make no sense to be able to open all the doors and it would requitre a lot of level design time and memory space to have something on the other side of each door.
If no doors are locked then why do we need to remove this this expectation?
This is one solution. Should we have a message saying the door is locked? If so, what message? Should all doors make the same thud? Does that make sense for a metal door? If we go for different thuds, is the inconsistency too jarring? How much space do the thus assets take up? Is a keypad the correct design given the setting of the current level?
So which events will cause the door to unlock or lock for both players and which will cause the door to lock or unlock for only one?
Yes. Now, how do you propose we deal with the memory issue created here?
What if the door is only usable by players with a certain key or character type?
It's not a question.
Sucks for those who didn't pre-order. We're now the subject of an internet hate capaign because our game is broken. Or, we don't get as many pre-orders as we otherwise would have.
Every one of these questions is a decision that has to be made. The decision depends on the type of game, the resoucrces avalable (both in terms of hardware and developers), and all the decisions you'e made already.
And the point is, this is just doors. You have a similar lot of questions for any other item in your game.
Fine. My solution here is incorrect.
Break down the UI into simpler components. Although to be fair to GGP, this does also apply to level design.