Jump to content
  • Advertisement

Eidetic Ex

Member
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

133 Neutral

About Eidetic Ex

  • Rank
    Newbie
  1. Eidetic Ex

    Idle: Wished-for programming language design?

    Optional markup used for function argument validation and range restriction, shown in the IDE's "intellisense" tooltips as well. "void fun(validate(arg < 100) int arg)" would cause an error if arg is greater-than-or-equal to 100. "void fun(range(5, 10) int arg)" would automatically clamp "arg" in the 5-10 range before the function body executes.   Given just how much of programming is mathematics, these always seemed like a no-brainer to me but I've yet to use a language which implements something like them.   Fixed point decimals as a primitive type instead of having to rely on 3rd party APIs or rolling your own. They solve so many audio and video problems that I don't understand why we keep trudging on with the pitfalls of floating point numbers in languages that are typically used for game development.
  2. Eidetic Ex

    Cinematographer for game dev?

    No idea if it's normal. But it's something I've been working out the design for awhile now. A camera system which makes use of a camera that simulates dolly on track, cranes, running man, and even some very slight jitter to simulate a steady cam.   The steady cam is one I actually took to simulating after paying very close attention to a marathon viewing of LotR trilogy. I noticed that even though the camera shots were for all intents and purposes steady, there was a very slight jitter in the viewing angle. Adding that into the view matrix to emulate it with a game camera made a world of difference. Even though the scene used was ugly programmer art, the steady cam one just felt more alive. The same kind of feeling when going from a camera that exactly follows a character to one that has a more springy follow pattern.
  3. Eidetic Ex

    Game Structure Question

    Since you mention XNA. Before I ditched XNA handled Day/Night cycle by create a game component that only job is to calculate things related to the atmosphere.   The update method did the following in this order: 1) Increment the time (stored in julian date format). 2) Calculate the position of the sun and moon (google it, so awesome). 3) Update the sun and moon's directional lights based on their position. 4) Attenuate the moon's light based on two factors: how far the current time is away from lunar noon (another julian date based equation) and the dot product of the sun and moon light direction. 5) Calculate fog factor based on how close the sun is from sunrise (another julian date based equation).   A lot of other things too. Storing the date and time in julian date format turned out to have a lot of really cool side-effects thanks to astonomer's work with the format.
  4. I think you may want to actually create a game or two before you even bother with trying to crate toolsets, or at least get onto a team with game developers that are looking for a guy that'll handle toolsets. Doesn't have to be a big game, just something to get your feet wet so that you know what all goes on inside a functional game from first hand experience.   Perhaps this will help you understand the sort of things we do for our data files. The following is a rough XML spec for a dungeon format. The final form changed a lot, but this is the one we used in our earliest working version of the dungeons for the game it was used in.   <Dungeon name="Dungeon Name"> <!-- Total size of the dungeon --> <Size> <Width></Width> <Height></Height> </Size> <!-- These would likely be in multiples with a From location as well if there are multiple entrances for a given dungeon --> <PlayerStart> <Room>Room Name</Room> <Location> <X></X> <Y></Y> </Location> </PlayerStart> <!-- Textures will be listed up front to avoid stuttering due to late loading --> <Texture name="Name used to refer to texture"> <Asset>File path relative to the game folder</Asset> <!-- Optional global tint applied to the texture --> <Tint> <Red></Red> <Green></Green> <Blue></Blue> </Tint> <!-- Optional pixel shader can be used to transform the appearance of a texture to add some spice --> <PixelShader asset="Path relative to the game folder"> <Parameter name="">Value goes here</Parameter> </PixelShader> </Texture> <!-- Post Process effects run over the entire screen (minus the GUI) after the scene has been drawn --> <!-- For example: in a cold environment we may want to lower the color temperature --> <PostProcessEffect asset="Path relative to the game folder"> <Parameter name=""></Parameter> </PostProcessEffect> <!-- Rooms are indivual scenes within the dungeon connected to at least one other room --> <Room name="Room Name"> <!-- Connections establish where each connector to another room or exit is located within the room --> <Connection destination="Room Name OR EXIT_TO_WORLD"> <Area> <X></X> <Y></Y> <Width></Width> <Height></Height> </Area> <!-- Optional graphic to display for this connection --> <Graphic> <Texture>Texture Name</Texture> <!-- Optional source rectangle, if not specified entire texture is used --> <Source> <X></X> <Y></Y> <Width></Width> <Height></Height> </Source> </Graphic> </Connection> <!-- NPCs are computer controlled characters that behave according to the AI used for them --> <NPC name="Name of NPC"> <Location> <X></X> <Y></Y> </Location> <!-- Optional floating point scale to change size of NPC --> <Scale> <X></X> <Y></Y> </Scale> <!-- Optional tint --> <Tint> <Red></Red> <Green></Green> <Blue></Blue> </Tint> <Animation>Name of animation</Animation> <AI>Optional name or type of AI to employ for this NPC</AI> </NPC> <!-- Graphics are loosely placed to form the look of the dungeon --> <Graphic> <Texture>Texture Name</Texture> <!-- Location and Size within the level to place the graphic --> <Destination> <X></X> <Y></Y> <Width></Width> <Height></Height> </Destination> <!-- Layers are to simulate depth, only graphics on the same layer should collide with player --> <Layer></Layer> <!-- Optional source rectangle, if not specified entire texture is used --> <Source> <X></X> <Y></Y> <Width></Width> <Height></Height> </Source> <!-- Optional tint --> <Tint> <Red></Red> <Green></Green> <Blue></Blue> </Tint> </Graphic> </Room> </Dungeon>
  5. I generally stick with.   int DoSomething(); // return a single value void DoSomething(int* const result); // multiple value   If you've never seen const in that specific position (between the pointer and name), it means you can change the data but not the pointer (barring any goofy tricks).
  6. Design is an important part of any important system. I have a hypothesis that if every programmer were to suddently treat planning and design as important as they treat actually writing code, our minds would be blown away by the initial quality of software. However it is important not to over-design a system, every step of the way you should be asking yourself (and any concerned team members) whether or not you really need the feature your thinking of adding to the design.
  7. Eidetic Ex

    Component programming. I think?

    If you plan to roll with a component based system, be sure to read up the chapter of Game Programming Gems on the subject. It presents a really simple way to handle components and some great guidelines to use when developing your own component system.   However in terms of message type systems. I found the Observer-Subject implementation in Intel's Smoke demo to be really interesting. In short subjects can publish changes, observers recieve notification of the changes. A change manager sits between them queueing up changes until a function call is made to begin distributing changes. The change manager also manages the associations between observer and subject based on bitmask of interest they have in common. It's an effective system that forces you to keep your code bundled up nicely and easily seperable.
  8. I think it has to do with the things we do for rendering a game. In order to render an object we need a way to represent it's position on the screen. However we don't know when we are writing our code what the resolution of the user's screen is. It makes sense to represent that screen in a common coordiante system and abstract the screen size away. We also need a way to represent the game world's coordinates, which can cover any range your game calls for. Once we have a coordiante system we need a way to move things around, rotate them, scale them, skew them, and whatever other transforms you may come up with. Once you examine all of these requirements and have a rudimentary understanding of vectors and matrices you realize that's really the only way to go to keep things generalized enough to cover majority use cases while still being efficient enough to process at high speed.   I remember my days of stubbornly clinging to integer coordinate systems, came up with all sorts of wild things to cover transform in arbitrary order. I facepalmed hard when I finally accepted a challenge to learn how to work with vectors and matrices, tons of code replaced by just a couple hundred lines that could be reused over and over again.
  • 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!