This last month I’ve really been rethinking the way I write code, with a lot of help from the book “Clean Code - A Handbook of Agile Software Craftmanship.” I would recommend it to anyone, as @rangerplus10 did for me. As a result, the current revision of Lexicon is far more efficient and usable than any other previous write. I’ve finished so much in such a short time, and I’m really happy with how it’s coming out so far.
This video shows off the new main menu:
This one shows off basic gameplay:
Tomorrow I’ll be posting a video showing off multiplayer, which includes a working lobby and tracking the movements of other players throughout the map.
PS: I know the main menu’s pretty boring right now, and all of the panels/buttons look very similar. Trust me, I’ll be changing it sooner or later.
Update 1/30/13:
This video shows off the multiplayer lobby, and multiplayer gameplay. The server runs in the background as the host plays the game. The host is also a player in the game, meaning you don’t have to have a seperate instance of the game running in order to play on multiplayer. However, it is suggested that you have a pretty fast processor in order to handle both the client game and the mutliplayer.
Also, if there’s anyone that would like to help test the multiplayer, I can upload this version for download. You’ll need Hamachi 2 to be able to help test it right now.
Would anyone be interested in making some “modules” for the player class? Here’s a basic rundown:
The player class has a List of modules. Currently, the only module is ParkourModule. This allows the player to climb walls of certain heights. You extend the Module class, which contains an instance of a set of things called “attributes.” The attributes contains access to the physics space, the player’s node, and basic information such as which keys the player is pressing, the camera, walk direction, move speed, and so on. The parkour module works by using ray-casting to test for surfaces in front of the player. If there is, and the player jumps, it adds (0.0, 0.1, 0.0) to the walk direction for every frame for about a second. This allows the player to “climb” walls of a certain height, or leap over obstacles faster than regular jumping.
Other example modules could be things like modified-speed modules, better ability to see certain things (like seeing enemy objects) (could be done with SceneGraphVisitor, find all objects with userData team that’s not equal to player’s team, mark them in red, put them in GUI bucket?), and really anything else you can think of. It’d be interesting to see what kind of things people come up with. If you’re interested, just PM me and I’ll set you up with a recent build. You can use the ParkourModule class as an example.
It’s been a while since I’ve updated here, so this’ll be a big one:
-Added weapons to the game (Pistols, snipers, and assault rifles right now. Shotguns, SMGs, and knives coming soon)
-Added weapon customization to the game, including colors of weapons.
-Added savable/loadable Weapon classes
-Added working MP, including a lobby and many other things
-Added the ability to shoot and kill other players
-Fixed exiting to main menu.
-Fixed server disconnect crashing client
-And a million other things I forget
Next things I plan to add:
-The rest of the weapon types (at least some customization for them)
-Vehicles
-More maps
-Ammo limiting for shooting
-Give another attempt at animation
Annndd, without further adieu:
-Destructible building physics (Now with a few new ideas!*)
*I’ll be attempting to add structural instability testing, so that walls, floors, and things like that check stress based on a few major defined points (Not every frame, and not on the render thread either. That’d be overkill.), and will collapse if this stress level is too high.
@nehon My internet went out halfway through the upload, I’ll be restarting it shortly.
@erlend_sh I just started on some base code. The production pipeline is much more simplified now, allowing level modellers to simply place a marker model, like a simple box, where they want a building. In the editor, naming the marker model something like “_B-Tower” would go to the folder “Maps/this map/Buildings/Tower/” to load the corresponding models, materials, and extra data like that. There’s common buildings as well, marked by “_CB”, which will load “Maps/Common/Buildings/building name.” Outside of that, I have a few ideas for how I can make the process a bit less CPU intensive. I’ve already been messing with some new ideas on the old Lexicon code. I managed to get the FPS up from around 15 when I’ve got everything destroyed to a bit over 30 at times. Now, with the general performance being better as it is, I’m sure the buildings will be a lot more do-able.
Oh, and I’m using Nifty for the GUI. I just made my own panels and stuff.
Another update! This time, the video actually works!
-Added base for destruction and grenades
-Synchronized grenade throwing and explosions with server
-Fixed lag problems where having small amounts of a building destroyed would be unplayable. Now there’s a very small framerate drop.
How did you do the destruction? It looks pretty cool. Are you only getting 30fps because of your current hardware, or is it mostly code efficiency issues?
@andrew.glassman
How I did it: http://www.indiedb.com/games/lexicon/news/building-destruction-physics
It’s only recording at 30FPS because that’s what the VideoRecorderAppState caps the framerate at. You’ll notice it doesn’t change at all. The usual framerate is around 80-100FPS running on:
Phenom II X4 925 @ 2.8GHz
Radeon HD4350 512MB DDR2 (really bad video card)
8GB DDR3 1066MHz
This weekend I’ll be benchmarking on a much better system:
@erlend_sh Yeah, I know it’s looking pretty basic as of right now. It’s not really supposed to be high-detail yet, I’m just trying to get basic functionality. Believe me though, when I actually take more than 30 minutes throwing together models, they come out much better. I expect to spend weeks on a single map before I’m even partially satisfied. Speaking of which, I’m gonna start on a new map soon.
General info stuff:
I’ve got buildings to a point where I feel like they’re as finished as they should be for now. Next in the list of things:
-I’ll be starting on learning animation in Blender, since I can’t find a way to get my animated models from 3DS to Blender.
-I’ll start messing with sounds
-I’m thinking about a different weapon system again, but the basis will stay the same. If I decide on it, I’ll give more info.
-I’m starting on a real, detailed map soon. I plan to put lots of thought into the design and layout, so hopefully it’ll come out good.
Heh I don’t doubt your modeling skills, I was just suggesting a cheap & super quick way to give you an immediate image of what your game would look like with higher def assets, as well as giving it a PR boost for sure.
By the way I posted on your IndieDB page and never got a reply:
Two questions:
Are there any added complications with models not made from scratch, e.g. if you buy a model pack and want to apply this method (fracture script) to those models?
What modeling tool are you using? And, are you completely tied to that particular tool (for making fractured models)?
@erlend_sh I replied to it. It never gave me an email that you commented, I guess I just missed it. >.<
I'm using 3DS Max 9 and Wings3D. I mostly do all the modelling in Wings3D, then put it through 3DS to do the texturing, renaming, and other general things, then export to .3DS, into Blender, where eventually I'll be doing animations for weapons and players and stuff, then to Ogre XML.
@andrew.glassman said:
@vinexgames Great breakdown on how you accomplished the destruction. Using the group names in the mesh to define it's properties was a great idea.
Thanks! I’ve really been trying to optimize it, while at the same time getting it to behave more realistically. I’m in the middle of finishing up structural stability testing, and surprisingly I was able to keep the performance cost next to nothing.
Small update:
Recently I’ve been working on some pretty random stuff around the core of the game. I’ve modified a lot in the building destruction, attempting to make it more and more efficient. I feel like I’ve got it to a point where it’s not getting any better with all the things I add. Recent stuff I’ve done:
+Mostly finished structural instability testing*
+Started on base code for different particle effects**
+Rewrote firing code a bit, it’s a bit more efficient now
+Optimized the major update loop for players
I have a good amount of work put into this. It’s an optional aspect to the level design. When you model a building, you put boxes around each chunk of it (for a small, 4-walled, 1 ceiling house, all 4 walls and the ceiling would have a box around them). You name the boxes “_X” to denote that they are integrity check points. After this, you denote it’s ID, and it’s relying IDs. So, if you had the small house, with 4 walls and a ceiling, each of the 4 walls would be something like “_X1”, “_X2”, etc. The ceiling would be “_X5:1:2:3:4”. This denotes that the ceiling relies on the integrity check boxes 1, 2, 3, and 4.
When the game loads, it uses the world bounds of these boxes to find how many building parts are inside of it that aren’t fractured yet. Then, every half a second, (on a different thread of course), I iterate over each one of the integrity check boxes, find how much is left of the original parts, and divide by the original parts. Then, after all of the percentages are updated, any integrity checks that depend on others add up all of the dependency’s percentage-integrity, divides by how many of the dependencies, and checks for how stable the building is statistically.
Pseudocode:
[java]
protected void updatePercentage() {
if(!isCollapsed) {
int numAlive = 0;
for(BuildingFractureControl bfc : internalFractures) {
if(!bfc.isFractured()) {
numAlive++;
}
}
percentage = (float)numAlive / (float)originalNumOfFractures;
} else {
percentage = 0.0F;
}
}
…
protected void checkForCollapse() {
if(!isCollapsed) {
float percentages = percentage;
for(IntegrityTracker it : dependencies) {
if(!it.isCollapsed()) {
percentages += it.getPercentage();
}
}
percentages /= dependencies.size() + 1;
if(percentages < 50.0F) {
collapse();
}
}
}
[/java]
** I've been messing with ParticleInfluencer stuff to see if I could get a particle effect that collides with the geometry around it. I planned to do it by ray casting, so it could obviously only be done with a small number of particles at a time. The plan was just to cast a ray from the particle's position, in the direction it's travelling, with a limit of it's current velocity. If it hits anything, bounce the particle off. Eventually I'd get stuff like bounciness, etc. involved but right now I'm just working on getting the basics.
So that's what I've been doing lately. Any criticism is welcomed.
Nice system. I like how you keep things simple, and they just work.
As for the system not getting any better for the things you’re adding: It sounds like you’ve hit the 80/20 wall. Usually when I hit his point in a coding project, I’ll take a step back and determine if there are other areas I could focus effort to a greater end result. In your case, maybe take a step back, and look at the workflow to determine if there are any pain points.
