Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

124 Neutral

About Sturm

  • Rank
  1. Interfaces are a great tool to keep you OM clean and easy to extend. So if you aren't planning on others (including yourself) writing extensions for your projects there is really no need to do them. They are also very usefull if you are communicating across tiers (server/client etc) or are integrating with legacy code. But for small selfcontained projects it often does not pay out creating any interfaces.
  2. Sturm

    C# Best way to extend array

    Well there are a lot of ways to do this. One way would be to create a 2d list of elements of a custom type, but as you asid creating 65K of objects isn't really a good option. You could instead go with virtualization since most tiles would the same and you most likely only have a limited set of states you can reuse these. You would still need your list of ints, but now you simply map a int to the specific map data. Instead of using a array of fixed size you could simply use a list of int and just keep the difference in the list. This would also limit the mem footprint, it might even be worth keeing a second list for the visibility this way you wouldn't need to keep two instance data (visited/not visited). Just a few comments.
  3. Sturm

    [C++] Class design help

    Quote:Original post by tasen Another issue I didn't think of is dual display devices (i.e. SLI) and dual (or more) monitors. I'm not sure how I'm going to accommodate them yet :P I think that you shouldn't worry about this at this point, if you've factored the device specific code into a seperate assembly you can expand this to includee multiple monitors at a later time. There are many factors to consider when doing more than one monitor and not all games are suitet for this. Quote:Original post by tasen Would you be able to elaborate a little bit? I'm not quite sure I'm understanding you here. Do you mean to hide the window handles so that users don't have to worry about them? Yes that's exactly what I mean, also this will be different depending on the framework you are using opengl/dx/sdl so hidding this is helping application (game) developers. I follow a simple rule which simply states that make it easy to develop a application (game) using the framework. Things like handles devices ect are a bit confusing for someone who never worked with graphics before. Also expose as few assemblies as possible as this will streamline the application development.
  4. Sturm

    [C++] Class design help

    I can't help but feeling that you might want to move a little further. Why not abstract the handle. Not having read any code I think that you are bound to a window/form, you might want to hide this, and also expand this to be a control instead. This means that working with your framework the developer shouldn't have to worry about handles. Just create the control he wants, either a window or a control, and pass it to the framework, should be enough. Another thing should be to move anything platform specific into a specific namespace and create your own abstractions to encapsulate these. It's a lot of extra work but I always find it well worth the work.
  5. Sturm

    Physics bottlenecks

    Have a look at PhysX physics engine.
  6. Sturm

    Art in indie games

    Quote:Original post by JBourrie My suggestion wasn't "make the whole game before you have an artist". It was "prototype the game and make sure it's fun before you have an artist". I really don't think you can prototype a game. There are section you can prototype, effects, but not the full game (Unless you are creating tetris again). Quote:Original post by JBourrie Consider Half Life 2: they made every level using orange walls first, balancing them until they were fun without flashy graphics. Then they handed the levels off to the artists to make them look good, modifying the gameplay in the levels when needed. There was a back-and-forth, but gameplay was paramount (as it should be... we are creating games). I do believe that HL2 was storylined before the first line of code was written. Though I can't say for sure as I wasn't part of the team. But I'm very sure that they knew where they wanted to take the game before they started to do it. Making games is similar to making movies. Before you start to shoot the film you need the story. But having the story isn't the same as having the storyboard. Quote:Original post by JBourrie "Don't start coding until you have the storyline ready?" That recommendation makes my ass hurt, seriously. I don't mean to be rude, but a storyline doesn't mean dick if you don't have a game that's fun. ... Once you know your game idea is solid, then you start making the monster that explodes or melts into green ooze or whatever, while coding up the main game. I think you are misunderstanding me here. You think of the storyline as the storyboard. But these are not the same. How do you know if you have a sound game idea if you do not have an idea of what you are going to create? You will need some kind of storyline in order to know where you are going with the game. You cannot just "take it as it comes", games, like movies, today have to be complete, they need the red line which makes sense to follow (It might be a insane red one, but it has to be there). I, and many I know, get fustrated over games/movies where the story doesn't make sense, where the ending was quick and dirty just because the time lacked to make the story right. Quote:Original post by JBourrie Yes, you want to have some idea of how you'll get art. But I wouldn't kill myself over figuring out all of the art assets until you know what is necessary to make your game fun. No art is needed for a prototype, and only a small amount of art is needed for a first playable (however, that art should be indicative of what the final game will look like). At the time where you get the artists in your crew you should have a clear idea of where the game is going. I'm not saying that it needs to be a fixed paved road, but you need the direction. Creating games is like creating movies (Many games are starting to look and feel like movies): 1) Get the right story (storyline) 2) Get a manuscript (storyboard) 3) Create concepts 4) Start shooting the movie (coding) And just like movies there will be scenes you'll cut out, redo over and over until it's right, cut out because they didn't work, and add because it feels right.
  7. Sturm

    Art in indie games

    As art has a huge influence on how you percieve your game, it has a very important role. You might think that it would look cool if a monster died in a pool of green acid, and you start coding this using some kind of crappy monster and it looks kinda ok. Then comes the monster design along a the artwork, and suddently the green monster in a green acid pool isn't cool, it would have been a lot better having it blow up in a electronic discharge. This scenario is bad in two ways, first you used a lot of time getting the acid death thing working, maybe even got the animators working on a acid death. Both the time and work is now wasted (Unless you find another monster and let him die in the acid). But you now have to start over and create the lightning explosion. Quote: Art made too early may have to be scrapped when you discover it no longer fits the game you are making. And vice versa, the game tends to change as the graphics envolves. Get concept art as much and early as possible, don't start coding until you have the storyline ready, and try to get the storyboard ready before coding. Most of us need visuals to imagine it, how would you create the black moon?
  8. Thank Dean, thats exactly what I'm looking form. I was just hopign that there were alternatives to shell extensions. Thanks alot all.
  9. Sturm


    I would guess that location of your nightclub is important, reputation is also a major issue. The more good reputation you've gpt the more you can charge and more bands want to play. The more famous the bands playing are the more your reputation raises. ect.
  10. I did, well not 'all' of them, and I might have overlooked the one that covers this. Any ideas of where it could have hid itself?
  11. Hi All, I'm trying to display a game file as a folder in Windows Explorer. As many resources are 'simple' files and many graphic designers are used to using explorer, it would be easier if they could use that to pack the files, similar to ZIP files. Do you know any example code or articles on this?
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!