About this blog
Selected articles from the jMonkeyEngine blog, covering open source, graphics programming and general game-dev practices.
Entries in this blog
Almost five months ago now, Rickard Eden posted the first of many development updates following his upcoming Applet based game, Hostile Sector. He has since become a core contributor to jMonkeyEngine, freely sharing useful experience and code. Yesterday we had an extensive talk about Rickard's on-going project and the challenges it presents. Considering I'm in Norway and he's in Sweden we could have practically carried out this interview with two cans and a string, but then I wouldn't have this handy transcript to share with y'all.
I already know you've got an impressive background in games. But why don't we start by recapping that for the reading monkeysRickard: Ok, not sure where to start... Yes. I've been in the industry for a while, mostly working with level design and later game design and production on some of the scandinavian developersErlend: In one of my favorite game companies, DICE!Rickard: Yes, it's one of my favorites too But now you're doing your own thing, making Hostile Sector. Can you elaborate on that decision just a little bit?Rickard: I took that decision long before starting on Hostile Sector. It was one of those famous "crossroads" where I felt I wanted to try doing things on my own. Even then, the plan was not to become an indie developer full time, but rather to use my past experience to be part time game design consultant, while working up my programmer skills.And is this your first foray into indie game development?Rickard: Actually no. I have a couple of titles in the trunk. One is Room Boom: Suburbia. A board game/puzzle hybrid (inspired by games like Carcassonne). Another is Blockstacker, a puzzle game originally made for browsers, that has been ported to android recently. None which has been exceedingly profitable, though So one could say indie development is something you know you want to come back to, rather than something new "just for the kicks"?Rickard: Yes, certainly. Although I wouldn't mind going back to the regular industry either. They both have their charm, and it's the creation I enjoy. But I like being able to do a little bit of everything.Erlend: Right. Creation is king!
Now we know where you're coming from, time to get gamey!So I've played, hmm, would you call it an "early tech demo" of Hostile Sector?Rickard: Yes. It was a while ago, and it was quite rough around the edges then. Still some things to weed out, but it's getting there.I gotta say, I can't come up with an easy category to put it in. Could be that the genre as a whole has just slipped by me, but if I had to put a label on it I'd say "Commandos-ish" I guess. What does a short version of your elevator pitch sound like?Rickard: Basically, what I'm aiming for, is taking the core from classic tactical games, like "Jagged Alliance" and the "UFO: Enemy Unknown" series, to a new multiplayer format, which is easily accessible online through your browser. Add some strategic elements and soldier customization, plus social functions, and there you have it.'Browser-based' - oh it's on now! So this is a pretty big one. Did the choice of making a browser based game come before or after the design itself?Rickard: The concept of a persistent, multiplayer, online, tactical game (long one) has been with me for several years, originally being RTS, I ditched it for networking reasons. "Hostile Sector" was conceived as an android exclusive 2D game, but realizing I would miss out of a prominent chunk of users, I decided to go the browser path first, and port it to android later.I'm guessing the idea of Android is what prompted you to code it in Java. Was that the only reason?Rickard: Well, java is what I know best, and knowing its cross-platform capabilities led me in that direction. Now, only the "tactical" client is java, which makes it trickier to port it, but since jME aims to have full Android support, I would want it to show up on Android in some form later on.3D games played in Applets is not a common thing. Has the Applet route presented any challenges worth speaking of? Any cautionary tales for developers on the fence?Rickard: Any games at all played in applets is not a common thing I think it does pose a couple of challenges. One is the sandbox in which it operates, it's quite strict, if you don't want to use a certificate, you need to know what you can and can't do (like accessing anything that is not on the server from where the applet is launched).Erlend: Making an applet with jME3 was simple enough though? Rickard: Yes. About a year and a half ago, I was prototyping another game, and took my first steps into 3d programming with jme2. I remember setting up an applet was a real hassle. In jME3 (jMP), you just check a box, and upload the results.In your own words, "the art [assets] are currently a mix of stock art and my own creations" - what will your final art pipeline look like?Rickard: for this project, the plan has been to utilize stock assets and contractors as much as possible to keep overhead low. Since I'm going for a fairly common/realistic style, there are plenty of assets made already. So I buy art assets (although lately I've been doing more of my own), take them into Blender/Gimp, and modify them. Then into jMP to create/assign materials.Erlend: Hmmm yeah. Following up on that a little; we've seen many people on the forum having trouble with stock assets, often times because they're not optimized for games or have gone through odd export/import schemes. Have you pretty much dodged the bullet so far?Rickard: It's something I've noticed as well. On many of the larger sites, you don't always know what you'll end up with, but there are smaller companies out there, focusing on game assets, albeit being a bit more expensive. In some cases, I've come to realize I could have done the model myself in the same time it took me to optimize it. This is one of the reasons I'm doing more myself nowadaysWell then, let's round this up! jME3: The good vs the bad?Rickard: I really like the focus on tools in jme3. Having worked a lot with content, I know the importance of good tools. I also think it's what can make a difference in todays middleware market. I also think it's a good move to utilize other open source libraries (like nifty gui, and bullet). As a developer, it means I have access to more documentation (since they're more widely spread). jME3 is still in alpha, and thus there are still issues and API changes. Things break. But, engines break in professional environments as well (and it's equally frustrating )Erlend: well, let me put it like this. when you were getting to grips with the new jME3, did you encounter something that made you think "hum, I see what you did there, but why?.."Rickard: I'm not really "low level" enough to reflect on engine architecture. If I looked into the core, I would probably ask that question all the time For me, jME3 is a tool I use, like an electric screwdriver. I don't need to open it to see how it works, as long as it does what I expect it to... Well, not entirely true, but true enough.
Thanks again for the interview Rickard! For more information on Hostile Sector, here's the link again: http://www.mindemia....sector/info.php
If you want to help test the game as it progresses, check out the frequent development updates on our forum.
Three days ago, @pspeed posted some development snapshots of his two-week project, Mythruna. Several new Minecraft-inspired projects have been popping up lately, but this is by far the most impressive one we've seen. We promptly set it up with a dedicated forum and arranged for an interview to discuss this trending topic.
So, you sort of popped up out of nowhere. Who are you?
Paul: Heheh... I'm Paul Speed. Been developing software for a long time. Usual stuff, started coding when I was 10 or so but just really simple stuff. Got my real career start on C/asm work in the early 90s. I've been coding in Java since around 1998. Dabble in art, music and I always wanted to do game development so that's always been my hobby.
My current "paying job" is doing data visualization work, though not so much recently. I also have a background in graph databases and have a few open source projects out there. I had a small name for myself as developer of some third party tools for Neverwinter Nights but other than that not much public 'game' stuff.
The data vis work I was doing was using Open Scene Graph with our own in-house Java wrapper. I looked at jME about 4 or 5 years ago or something when we were looking for something more pure Java.
Yeah, so on that note, according to your profile you've been a registered member of the jMonkey forum for 5 whole years . I guess your first try with jME didn't amount to a whole lot then?
Paul: So, I code as a hobby as well as a career and at that time I was trying once again to get some kind of terrain engine off the ground. I played with jME for a bit and had some custom shaders written, little spinning brickwalls and whatever. But so much of it felt unpolished or convoluted. Open Scene Graph was a pretty clean API but the C++ -> Java disparity was pretty hard because it was a deeply vested C++ API using all kinds of C++ 'goodness'. At any rate, I was discouraged by jME2 and considered writing my own LWJGL based scene graph similar to OSG and ultimately got distracted by other shiny things. I can't code in C++ in my own time... just too painful.
hah, I'm pretty sure the jME community can relate.
Paul: But my terrain engine ideas lay dormant and festering. I've read the various GPU gems articles and other material. I started figuring out stuff I liked and stuff I didn't and sort of had this idea on how I wanted the world to work conceptually. I'd had an interest in fractally generated terrain and had written my own GUI terrain configurer thing back 5 years ago. My goal was to have some kind of game that I could play without knowing where everything was. I wanted to be able to have fun in my own game.
So now you're back with guns blazing. When did you first hear about jME3, and what made you go all in all of a sudden?
Paul: Well, I was playing Minecraft almost obsessively for a week straight... got on a buddy's server and we were building all kinds of cool stuff. Kept running into places where I wished that game had gone and something snapped inside my head: The light bulb came on. I had been trying to think of photo-realistic terrain rendering but I could do nearly everything I wanted to do by using an engine with a block-based world. And the engine architecture is not so dissimilar, really. As soon as I said to myself, "Why am I wasting time building block towers when I could be writing a game?", the new obsession began. So I peaked in to to see what jME had done while I was gone.
... and so glad I did.
we're happy too!
Paul: I downloaded the platform -- and I'll say that I'm generally distrustful of IDEs. But it was a great way to get started and figure out what was going on. I was literally up and doing interesting things within an hour. By the end of that weekend, I'd prototyped my environment effects and my geometry generation from the block data. It was excellent.
Sunday January 30th, 2011, I checked in my first code snippets for Mythruna. My beginning of turning that weekend's prototyping into something more tangible.
Did you evaluate any other engines before jumping into it?
Paul: What other engines? Not really. I'd looked around at other things all of those years ago and even then liked jME the best for the 'not written by me' back ends. So you were my first stop.
...and I saw no reason to continue on.
Indeed! Now, your motivations are still curious to me. By and large this strikes me as a personal, yet no doubt elaborate, "pet project". Are you doing this mainly for your own enjoyment, more so than anyone else's?
Paul: No, it's not just for me. The engine is, maybe, but I'd definitely like to see this go somewhere real and that's the plan. That's why I secured the domain, web site, etc.. It would be nice if I could earn some money at some point, though I'm ever the pessimist.
You're not afraid that the obvious similarity to Minecraft will cause issues? (I wouldn't wish fanboy hate on my worst enemy -- no disrespect to the Minecraft community, it's just an inevitable result of being worthy of fandom in the first place.)
Paul: It might. I'm billing this as more RPG though. Minecraft is all about 'emergent play' in my opinion. There's a tiny bit of 'found play' in there. I want to pump up the 'found play' a lot, add a tiny bit of role playing to get users invested in more than just their towers, while still allowing the emergent play and hopefully taking it to new levels.
I have some ideas that, if I can make them work, will just be so different from Minecraft. I do worry a little about fanboy hate, but I'm hoping the community has no reason to feel threatened. Actually, that's a strong motivator for this ultimately being 'for pay', as well. The last thing I want to do is come out with something free that undercuts that community.
I do have an end state in mind and loose plan for getting there... with an even looser timeline.
You mentioned "some ideas". Not something you want to disclose just yet?
Paul: Well, some I've already added like more non-cube block types, etc.. On the one hand, they make more possible when building, on the other hand they can be tricky to use and fit in given the limited sets of 'special parts' available.. And I hope that will appeal to the types that like these sorts of builder games. The "what can I do?" and "how can I do that?" mindsets. But that's simple. Beyond that it gets more experimental.
For example, I believe I can make craftable items using the same blocks. I have wood planks, wood pillars, etc. so why not allow the player to make chairs and tables and such which are essentially shrunk down chunks of world. I believe my engine will support this but I still have to do some testing.
Stuff like that. Trying to build smaller 'elements' that allow more diverse emergent play in concert. And on the other side, I want a living world.
Let's get one thing straight before we go a little further then. This is a project that you're doing on your spare time, for fun, but hopefully you'll get it to a point where it can become a revenue stream, possibly even big enough to become your day job; correct?
Paul: That is the ideal end state, yes. I'd like my obsessions to pay me instead of me paying for my obsessions.
And for the record, currently this project is occupying all of my non-family free time. I haven't even watched TV in two weeks. I hope to keep that up a while longer, I don't miss TV.
(we digress about the brilliant internet age for a while)
Currently you're distributing a non-obfuscated build and you're sharing a lot of insights on the jME forum already. if you manage to get this game to the commercial level, how will that affect the openness of the code, the licensing and so forth?
Paul: Good question. All of this is sort of open ended to me. If I can find a way to monetize and open source it at the same time, I would totally do that. I'm a big fan of open source and have three or four of my own projects out there now. However, I think that is unlikely to occur. I can't find a way to make that work. That being said, I'm not a fan of obfuscation.
What's amazing to me is that Minecraft has a whole community of modders which are essentially reverse engineering the game so that they can mod it. They distribute their mods as patches on top of the original code, all for a game they paid 15 euros for. Bottom line, I want to be as open as I can be within reason.
In short though, nothing is totally decided yet, right?
Paul: Correct. I know I want to earn money off of this at some point but I don't know how exactly.
To what extent to you see yourself doing this solo?
Paul: It's hard to say. I've worked big and small teams in my own career. I've been manager of software development down to just the lone-guy on the team. On the one hand, right now, I'm very nimble and all of my desirements are within my capability set. Even if some of it (like my shaders) might be ugly to someone with more expertise...
On the other hand, at some point, the project will start to stagnate without some additional input. However my inability to make promises or pay or whatever means that it would have to be a very specific set of events and relationships that developed to make it happen. I've been in startups that failed and I've been on teams that disbanded. Everyone would have to have their eyes wide open and be a 'perfect fit'. So I'm putting off thinking about it too deeply, until I start to feel the pressure of time or other factors that is.
Though, the art pipeline may need attention sooner than later. I'm not half-bad but I'm slow. I can model and texture most any inanimate object but animals and other animated characters will take me forever.
You're not planning to just make them out of blocks, Minecraft-style?
Paul: Ummm... no. Without getting too much into 'Minecraft comparisons', that world would look really strange with anything but block characters because everything is a block. In my world, blocks make up the base terrain but beyond that there will be slopes and round things, etc. that don't quite fit that model. I'm still trying to strike a balance but non-block characters will definitely not seem out of place in my world... block characters definitely would.
Think newer style lego versus old, without getting all crazy 'space lego' where everything is a special piece. I hope I appeal to the fellow Minecrafters that were looking for a little more and were disappointed when they reached bedrock, or the guy who built his really cool castle and then said "Ok, now what?"
lego & playmo, combined
Hmmmmm, interesting. Well now, let's get back on the design bit again before we wrap this up! you got me all excited about your "living world". No question, just freestyle it!
Paul: Living world = populated world. Part of the 'found play' aspect is in my minds eye I'd like to have villages that the user can run across maybe with people that go about their daily mundane jobs. That's on the "yeah, I wish" side of it. More realistically, if I have sheep and pigs then I ought to have wolves and tigers, and they should eat each other. I should be able to farm pigs and sheep if I want or go hunt wolves when they aren't hunting me...
Terrain-wise, the original motivation behind a completely morphable world was that terrain can change over time. Rivers could erode the land and change paths, storms could fell trees and so on. I'm not sure how much of that I can get in or will actually work in practice but those are the goals. Give the player the sense that there is something to explore over the horizon and that the world exists and does stuff even when they aren't in it.
"Emergent Play", "Found Play", and "Role Play" in any combination that the player chooses to explore.
Thank you for your time Paul, keep rocking those blocks!
*** Aftermath ***
Paul: All that being said, I try really hard not to directly refer to Minecraft all the time. I think this [type of gameplay] could end up being a whole genre and that's the way I'm treating it.
Erlend: Same genre, different games, like Halo and Gears of War.
Paul: Exactly. The "block world" of Minecraft was my inspiration, but it was more like a final piece of a larger picture.
Erlend: It's definitely a concept that's been taking off lately. And to my great delight as well, because as you've proven it really fosters a lot of creativity, in spite of starting out as something looking like a plane 'clone' of say, WoW (ring any bells anyone?). If you treat it as a genre and not a framework there's no end to what might come out of these games!
Erlend: I've said it in the jME team chat already and I'll say it again, Minecraft-esque beats WoW-esqe to a bloody pulp any day of the week.
While Mythruna is built with jMonkeyEngine 3, Minecraft is not. Both games however do have the Lightweight Java Game Library in common.
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 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 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
OpenSource.com just published this article, written by yours truly: Open source games: It's a team effort
- The Game
- Implementation Details
- Manager Classes
- Use of Controls
- Artificial Intelligence
- Use of jMonkeyPlatform tools
- The Future
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 To get an impression of the original game, have a look at some gameplay of the original version.
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.
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
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.
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.
MonkeyZone includes simple AI functions based on a command queue.
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.
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).
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 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".
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.
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.
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.
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
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.
The jMonkeyEngine Team
A lot of it is based on my experience with a game that I tried to do together with Kirill Vainer, the lead developer of jMonkeyEngine 3. Some GDnet oldtimers (well now, it's only a couple years ago) might remember "Radakan". Funnily enough, this game was in part the beginning of jME3, and I might write about just that and other benefits of open source game development in an upcoming article.
Last fun fact: This article was based on a answer I previously typed up over at gamedev.stackexchange.com:
Where to look and begin with open source game projects
It came to mind a while after just as a random pop-up in a conversation with the jMonkey team, and I realized an article could be made of it. I'm sure several others could do the same with some of their more memorable rants over the past few years, am I right?
Greetings fellow GameDev'ers,
We've made many appearances here before, but today I'd like to reintroduce the jMonkeyEngine project in the form of this developer journal. For those unfamiliar with us we've set up a nice and easy introduction that explains what we're all about and how we came to be. In short though, we're developing an open source 3D game engine entirely in Java.
As promised, here's our agenda, fully exposed:
This journal will mainly import selected blogposts from jmonkeyengine.org. The kind of content that merits an import is determined by its general appeal; if we've written about something that any game developer might enjoy, up it goes. We don't know for sure yet what we'll throw at this space, but expect some moderately useful banter on topics like open source, graphics programming and game development practices.
I sincerely hope many of you will find this journal worth your while. Expect fresh posts shortly!