While I won’t restart my entire game, I have and will rewrite parts of it as well - it’s perfectly normal.
Even if this project is a mess in its current state, what do you think about releasing the code?
It probably won’t give beginners a great introduction, but I’d guess an advanced user could find some nice inspiration in there (particularly movement and weapons, there’s so many different ways of implementing each).
Of course, your own decision.
(You could upload it to Google Code or Github if you don’t have any webspace available)
@rylius I was definitely planning on releasing the code! Some bits might even be helpful for beginners. (i.e. the extensive use of controls). The rest of it will probably be headache inducing. But I definitely plan on it.
That being said, if anyone wants to know how I did anything with Lexicon specifically, just message me and I’ll send you all the relevant code about it and explain it as well!
Hey, if we create a shared dropbox folder, can you give me the source? I would love to see how you accomplished things and carry the basis of this project on.
PM me about.specific things and I’ll give you the source for them. I don’t want anyone using the underlying structure of this game as a guideline because it is very inefficient. My new version of Lexicon is much faster and more efficient, and I’d be happy to give a full explanation.
It was my first game, so obviously there were some drawbacks. The major things:
I didn’t use AppStates at all. It was all just thrown into massive chunks of if-conditions.
I used lots of controls, but not exactly correctly.
I passed the AssetManager through a lot of the classes, and loaded TONS of stuff each time you’d go into a game, which resulted in massive memory usage.
The game was built very simply, and after a while I couldn’t find anywhere to put new code. I couldn’t fit multiplayer in because it was too crowded with other things and the game became unplayable.
In my new version, I’ve redone a lot. Things I learned:
Use AppStates. Use LOTS of AppStates. Namely, I have a PlayerAppState, MenuAppState, and GameAppState. The PlayerAppState manages movement, and just general things about the player. MenuAppState is for managing the menu. When I disable it, it removes the menu from the screen, and when I enable it, it re-adds the menu to the screen at the home menu. The GameAppState contains the world-loading data, the physics, and in general a lot of the basic control code for the world, including stuff for multiplayer.
I made a class called “AssetLoading.java.” In this class, I have a static DesktopAssetManager field and a static method called “setAssetManager(DesktopAssetManager dam).” Also, there’s a static AssetManager method called “getAssetManager()” so you can call this from anywhere and use the AssetManager without having to pass it through tons of methods and crowd up code.
Build your classes with an idea of what they’ll be doing. Think of how you want something to work BEFORE you start coding it. The weapon system in my game is a good example. I had a lot of fun with it. It involves lots of customization, packed into 5 classes: WeaponPart, WeaponMaterial, WeaponControl, WeaponPartSet, and WeaponNode. You attach all of your WeaponParts (extension of Node) to a WeaponNode, which, when told the weapon is selected, has it’s WeaponControl initiated and shows the animations for the weapon.
Haven’t checked his out in a while, and I must say the weapon system has improved greatly since I last saw it :). I have one question though, when you say, “… WeaponParts (extension of Node)…,” do you mean that the class WeaponParts extends Node? I haven’t touched the engine for a while (LWJGL does not like Mac Java 7 very much), but isn’t it better practice to create a new Node and attach a WeaponParts Controller (extends Controller)?
Hi vinexganes, could you explain to me a little how you did the weapon animation in front of the camera, for example when the player is moving?
Thanks, and by the way, this game is really coming along! I saw your new video (well, the one that was made in march, not so new i guess but I hadnt seen it before)
@rangerplus10 Yes, and in the newer version it’s done differently so there are no extensions on Node/Geometry/Spatial.
@8Keep123 If you mean how I kept the weapon in the viewport, it’s pretty simple. Make a Node, call it viewNode, and in the update method place it at the location and rotation of the camera each frame.
For animation, that’s a whole different story. In the case of sprinting, I had 3 Vector3fs in the class: sprintLeft, sprintRight and curSprint. SprintLeft was the vector that the gun would move towards on the left, and sprintRight was the vector the gun would move towards on the right. When you’d press the sprint button the code was sort of like this:
//Rotate it as well
Quaternion rot = new Quaternion().fromAngleAxis(find a good angleaxis to rotate the gun (i think i did like 80 on the Y-axis));
weaponNode.setLocalRotation(weaponNode.getLocalRotation().clone().nlerp(rot, interpRate); //Or something like that, i don't remember this part exactly.
