Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 04 Mar 2011
Offline Last Active Oct 26 2015 07:40 AM

Topics I've Started

Organizing Game Logic

21 September 2015 - 01:22 PM

So, I have a lot of the technical stuff in my game finished, such as graphics and pathfinding and it's all completely separated from the game itself. I am now starting to develop the game logic. Up until now, all of my game logic has been in a single class dealing mainly with game map generation. Now that I'm ready to experiment with actual game rules, AI and units moving around, I'm afraid my 'GameLogic' class is just going to become huge and unmanageable.


Is there any conventional wisdom regarding the division of labor at this stage that I should be aware of? I know I don't want a giant, confusing lump of code, but my predictions for what would make things cleaner often don't pan out.

Need some dynamic buffer advice

17 August 2015 - 03:36 PM

So I have this simple game engine that displays a 3D hex game board/map, that can support things like floating islands, river networks and cave systems. I have the map divided up geographically into cuboid chunks so that I can render only the parts that are near the camera and in the frustum. Each chunk has a series of dynamic buffers to draw the terrain, rivers, water levels etc. These buffers are often different sizes, as some map chunks have few rivers, or few water tiles, or sometimes in the case of floating islands there might be only one or two map tiles in the whole chunk, or the chunk might be completely empty space. This scheme is working great if I am just generating a map and displaying it. I draw what exists in my buffers each frame.


However, if this thing is ever going to be useful in a game, I need to be able to alter the map during the course of the game. It's time to make this thing change over time. But that means that I don't know the buffer's size needs at initialization time. I have to assume that every chunk is full of tiles, water and full of rivers, which in practice will be never the actual case. The problem is that not only will I have to waste memory (probably 5x as much) for empty fixed size buffers, but I'll also have to send a bunch of degenerate triangles for rendering, which is probably going to be some kind of performance hit.


All of a sudden my geographical partitioning makes a lot less sense. I wonder if any of you know of another way to handle resource data that changes in size in the described manner.

Insurmountable limits on a touchscreen interface?

16 April 2015 - 09:39 AM

So I'm at the point in my game development where I have to start deciding on a UI framework. Tablets are all the rage these days, but I don't use one myself. The reason why that is, is because I'm a PC gamer. I like strategy games and the occasional first person shooter, things like Crusader Kings 2, the Civilization series, that kind of thing. When I start making my game, it will be a strategy game of some complexity.


Every touchscreen game I have ever seen is a casual game where you poke at things and get a response. Have any of you ever seen a complex strategy game on a tablet? Please name them if you have.


What I'm wondering is, for the games I like to play and presumably make, whether keyboard and mouse is the only way, and that the touchscreen will never be a replacement for that. I worry that trying to turn a PC game into a tablet game is a fools errand to be strictly avoided. 


What do you think?

Time to decide on a UI Framework (SharpDX)

16 April 2015 - 08:53 AM

Ok, after a couple of years I've finished with my graphics engine! It has everything I need to make a game prototype now. The only thing left is to decide how I want to present various game data. The games I like to play (and also presumably make) are fairly complex strategy games, so I will need to present possible sortable lists, tables and dialogs etc. over the top of and along side of my main graphics screen.


I think I've already made a decision, but I wanted some other opinions on the subject because for me this is uncharted territory.


All of my UI experience to date comes from WIndows Forms. That is what I am comfortable with even though it performs miserably for something like games. However, XAML seems to have some promise even though I have no experience with it. Microsoft seems to be pushing that with the new WinRT stuff, but I'm not ready to force a Windows 8+ platform. I am still using Windows 7 and will probably end up skipping 8 altogether. That leaves me with mixing SharpDX with WPF I think if I want to get familiar with XAML. My research is heading that direction.


What do you think? Is that just a big waste of time or is it feasible?

Messing with the depth buffer for skybox effect

09 April 2015 - 02:09 PM

So I want to create a sort of dynamic skybox, with a standard cube map as the backround, and quads depicting orbiting planets and other celestial phenomena.


I tried creating a dynamic cube map, and before I succeeded I decided that this approach is really very expensive for what I'm trying to do, as there's only ever going to be maybe ten billboards floating around the sky. Rendering the 6 faces of a cube map over that is overkill I think. Just clearing the 6 faces had a significant impact on my framerate.


What I'd like to do instead, is draw the planets as I normally would draw a quad, but have them:


pass in front or behind each other correctly according to distance,

be in front of the background skybox.

be behind everything else. 


Can I do that with certain DepthStencilState settings, or does anyone else have any other ideas?


EDIT: If I make my projection matrix too deep, I'm going to have z-fighting issues with the other components in the scene, therefore I can't just make it 'real' by putting the planets far away.