• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
  • entries
    5
  • comments
    4
  • views
    18101

MonkeyZone

Sign in to follow this  
Followers 0
jMonkeyEngine

2295 views

With jME3 nearing its first stable release and many monkeys already getting their hands wet with creating games we thought it would be good to implement a demo game with jME3 to a) showcase jME3 and one possible way to implement a game with it and to B) verify the jME3 API in terms of usability ourselves. Furthermore the game is planned to stay as a community project that will be extended and improved to further test and showcase jME3.

So I wrapped up my ideas and started off with a blank BasicGame project in jMonkeyPlatform and one week later I already had a first version of a game including networking running. Yes, one week. I was baffled myself about how efficiently and fast one can write games in jME3. In that one week I got more done than in one full year messing with jME2 RenderStates chimpanzee-wink.gif Have a look at the first results:



It looks very simple and plain but in the background most of the system detailed below is already implemented and the best thing is the design makes it possible for others to edit maps, vehicles etc. in jMP w/o changing the code, allowing designers to contribute easily, if you feel like contributing assets or working on parts of the game code, drop me a note!

So keep your eyes open for updates and news and in the meantime read about the game implementation details below.



Table of contents
  • The Game
  • Implementation Details
    • Manager Classes
    • Use of Controls
    • Artificial Intelligence
    • Networking
    • Use of jMonkeyPlatform tools
    • The Future
      The Game
      Since the time I started working with jME I always wanted to create a game like Activisions "BattleZone" from 1998. This was actually the initial reason I started working with jbullet physics and because the idea was floating around for some time its also the reason why @nehon created the awesome HoverTank model. BattleZone was a FPS game with RTS elements or vice versa, however you want to look at it chimpanzee-smile.gif To get an impression of the original game, have a look at some gameplay of the original version.


      Implementation Details
      MonkeyZone is a physics-based networking game. Both clients and server run the physics simulation, the clients send input data from the human and AI players to the server where they are used to control the entities and also broadcast to the clients. Additionally the server sends sync data in intervals for all objects in the game to prevent drifting.
      When a human user or an AI presses a button/performs an action the actual logic is done on the server and the results are broadcast as data messages for the entities. When the entity is controlled by an AI the actual AI code that determines where the entity should move and when it should perform an action is executed on the client.

      Note that the way MonkeyZone is implemented is just one of the many possible ways to do a game like this in jME. Some things might be done more efficiently, some might be done in another way completely. MonkeyZone tries to do things the way that are most appropriate to implement the game at hand and it shows nicely how jME3 and the standard Java API can make game development easier and faster. Also note that the way MonkeyZone is designed is not scalable to a MMO style game, it will only work in a FPS style environment where the whole game world can be loaded at once.


      Terminology
      The game uses certain terms that might be familiar to you but maybe used in another way, so heres a quick rundown on the terms being used.

      PlayerLogical human or AI player that can enter entities and generally act, only exists as PlayerData "database" with an id.EntitySpatial with UserData, a world object like character, vehicle, box or factory. The base form is defined only by a String pointing to the j3o which already has all userdata like hitpoints, speed etc.UserHuman player using clientGroupGroup of players that play together (human and AI), for now thats the same as client_id of human player for all AIControl'd players originating from that client.ClientComputer connected to server
      Manager Classes
      The WorldManager does the main work of organizing players, entities and the world and synchronizing them between the server and client. Both client and server use this class. Some other managers like ClientEffectsManager only exist on the client or server and manage e.g. effects display.

      The gameplay is largely controlled by the ServerGameManager which does gameplay logic on the server, combined with the actions issued by the AI and user on the client (see below) it implements the gameplay. It extensively uses the functions exposed by the WorldManager to perform actions and gather data. This is also the class where the actions of the players are actually executed on the server to determine the outcome (ray testing for shooting etc.).


      Use of Controls
      Controls are used extensively in MonkeyZone for many aspects of the game. When a player enters an entity the Spatials Controls are configured based on the player that enters. For example when the human user enters an entity, Controls that update the user interface (DefaultHUDControl) or user input (UserInputControl) are added to the current entity Spatial.


      As entity capabilities
      Controls attached to Spatials are generally used like an "array of capabilities" that the entity posesses. So when an entity has a VehicleControl its expected to be a vehicle, when its got a CharacterControl its expected to be a character.
      Other Controls work completely on their own, like CharacterAnimControl which just uses the CharacterControl of the entity to check if the character is running, jumping etc. and then animates the entity if it has an AnimControl.


      To abstract
      Furthermore theres special interfaces for Controls that allow abstraction of different Controls into one base interface. For example ManualControl and AutonomousControl are interfaces for controls that manage the movement of a spatial in a generalized way. This way AI code and e.g. the UserInputControl only have to check for a valid AutonomousControl or ManualControl on the spatial to control and move it. The details of the movement are handled by classes like ManualVehicleControl and AutonomousCharacterControl.


      For AI functions
      A special Control called CommandControl handles the Commands that can be executed by user controlled players, see below.


      Artificial Intelligence
      MonkeyZone includes simple AI functions based on a command queue.


      Commands
      To implement autonomous AI players MonkeyZone uses a system of Commands that are managed by a CommandControl that is attached to each AI player entity controlled by the user. This CommandControl manages a list of Commands that are executed based on priority. For example theres a MoveCommand, a FollowCommand and an AttackCommand, Commands can however implement more complete behavior than that, e.g. the complete logic for a scavenging entity.


      Triggers
      The SphereTrigger is a TriggerControl that is also attached to each AI players current entity. It consists of a GhostControl that checks the overlapping entities around the entity its attached to. It can be assigned a command that is checked with every entity entering the SphereTrigger and executed if applicable (e.g. normal "attack enemy" mode).


      NavMesh
      For each map a navigation mesh is generated that allows the entities to navigate the terrain. Autonomous entities automatically get a NavigationControl based on the current map. The AutonomousControl implementations automatically recognize the NavigationControl attached to the Spatial and use it for navigation. The NavMeshNavigationControl implementation contains a reference to the levels NavMesh and implements a navigation algorithm similar to the A* algorithm.


      Networking
      Networking is realized in the PhysicsSyncManager which we hope to extend to a state where it can serve as a general sync system for physics based network games.
      The sync manager basically puts a timestamp on every message sent from the server and then buffers all arriving messages on the client within a certain time window. This allows to compensate for messages arriving too soon or too late within the constraints of the buffer, a future version might step the clients physics space different to compensate for network delays without "snapping".

      Gtc5a.jpg


      Use of jMonkeyPlatform tools
      All assets used in the game, like entity models and loaded maps can be preconfigured and edited using jMonkeyPlatform. For example, to add a new vehicle type, a vehicle is created in the jMP vehicle editor and UserData like Speed, HitPoints etc. is applied directly in the editor. When the model is loaded in the game it is automatically configured based on these settings, the same accounts for maps that are loaded, special Nodes that mark e.g. player start locations are recognized automatically etc.


      UserData
      Entities that are loaded from disk have certain UserData like HitPoints, Speed etc. that is used to configure the entity at runtime. jMP allows adding and editing this UserData so entity properties are editable visually.


      Physics
      VehicleControls, CharacterControls and RigidBodyControls with mesh collision shape for terrain and objects are generated in jMP and saved in the entity j3o file. When an entity is loaded, the type of entity is identified based on the available controls and UserData and it is configured accordingly.


      The Future
      I hope to get to talk about MonkeyZone some more when it gets more mature, for now have a look at the code and feel free to ask about it, if you want any new features, you are free to implement them chimpanzee-wink.gif

      MonkeyZone is hosted at GoogleCode, where you can checkout the jMonkeyPlatform project via svn:

      Team->Subversion->Checkout and enter the URL http://monkeyzone.go....com/svn/trunk/
      After downloading and opening the project, run a server first and then a client.

      Cheers,
      The jMonkeyEngine Team



      Source

0
Sign in to follow this  
Followers 0


0 Comments


There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now