Jump to content

  • Log In with Google      Sign In   
  • Create Account






The current game plan

Posted by CC Ricers, 20 March 2013 · 655 views

game architecture graphics screens game development
Bye-bye geo-clipmaps, here comes geo-mipmapping! I've converted my terrain rendering code to use it from now on. It's not fully completed but the basics work. I just need to fix up the holes that appear in the borders between different detail meshes. The terrain code has just gotten a lot more complex since I first started out. While it only still supports two textures, they can be sampled twice in different scales and blended to remove any semblance of repetition. The renderer is now running inside a game framework to manage states and different screens.

Posted Image

Now to move on to the game structure itself. I'm not too keen into drawing UML diagrams or other fancy charts, also because I have not gotten really comfortable with pre-visualization tools on the computer. I'd rather sketch them on paper and take some photos of it with a phone. Guess this calls for getting a drawing tablet (anyone have one, does it greatly increase productivity even for programmers?) However, at least I have a tree-like structure for my code organization.

This planning comes easier as I figure out the first thing I want to do with my terrain loader is to put it in a game state to represent the in-game map editor. I have barely mentioned it in this journal, but I made a puzzle game clone as a learning experience in building a screen and menu system from an XNA sample, where multiple states and screens run independently of each other. The game may not be 100% done, but its code is stable enough for me to be able to port the system into this new game. Because this would be the most complex game I've attempted, I look forward to seeing how far I can take it. With a loading screen and transition to game modes are in place, it will at least finally start feeling more like a game than a tech demo.

The graphics engine is still a work in progress so I will work on it together with making the game. The game code will be organized in three different areas: Core, Game, and Screens.

Core
  • Graphics engine (my own)
  • Physics engine (BEPU)
  • File saving/loading
  • Input
  • Networking
  • Screen system (from my last game)
  • Menu interactions
  • Screen drawing/updating system
Game
  • Game logic, AI
  • Player interactions
  • Game objects
  • Editor
  • Editing tools and functions
Screens
  • Background(s)
  • Loading screen
  • Menus
  • Gameplay modes
  • HUDs and interfaces
Core contains all the systems that deal with the lower-level workings of the game. Sending data to the graphics engine, setting up and managing physics (using BEPU for this one), input management, and the loading and saving of files all go here.

Game contains all the very game-specific logic that's all about setting the rules, game modes, and specific interactions with game objects. They all tie into Core in some way, depending on what they are responsible for doing. A more specific area, Editor would include all the tools and functions used for the game's map editor mode.

Screens can be seen sort of like game states and also like components that, when grouped together, can describe a game state or mode of behavior. They are loaded and ran from the screen system, and either specialize on displaying information related to the game, or tell the user what actions are available. Background screens, gameplay screens, HUDs, inventory screens, and menus would belong here.

As you may have noticed, the three groups tend to progress from low-level to high-level code. This was not really intended, but does give me a better idea of how to pass data around.

When the program launches it add a Screen to a list, which loads the content to be rendered. Here is the game loading a terrain in real-time, with some interactions handled by an "Editor" screen.

http://www.youtube.com/watch?v=HVjLSH02dwA

There are a few issues I have to take care of with the screens and graphics. Both the screen system and graphics engine are loaded as XNA game components, which means they draw and update automatically within the game, outside of the screen system's control. Although the content loading code is in the Editor screen, I need the option to make the explicit choice of what order the graphics should be drawn, so that any graphics that are set in a particular screen get drawn with that screen's Draw call.




Looks amazing. If ever you decide to drop the project hit me up! tongue.png Looks like much of the work you are doing overlaps the work we have done.

 

EDIT: Btw, this is looking great so far! keep up the amazing work

July 2014 »

S M T W T F S
  12345
678 9 101112
13141516171819
20212223242526
2728293031  
PARTNERS