Yep, especially Trackback spam. Harder to stop than comment spam. My current thoughts are “can you spam through Pingback as easily as Trackback?”
I’m too lazy to investigate this. For now, I’m going to disable both completely for my blog.
Need a way to check if we can fire at all. Should probably have like a CPlayer::CanFire() or something. The current framework for firing is somewhat buggered because there is no proper way of saying “you can’t fire.”
More thoughts:
Players are ALWAYS id 0 to 31. We no longer need the player set because of this.
Actors should store their location in CActor. So like m_octree_location or something. No longer need actor map.
Entities should always have a unique ID.
Perhaps all entities, including children, should be in the entity vector. When they are children they can possibly be handled differently.
Get rid of particle manager! If we have the above changes, the particle manager will no longer be necessary to update the particle emitters.
The above is probably quite a bit of work, but worthwhile. The current system is faaar to flaky.
Ok, so thoughts on initial gameplay. Want BuNg to be playable with as little effort as possible from here:
Unlimited ammo and stuff for now. Who cares.
I wonder if the monkey can jump. Maybe we shouldn’t let it.
Should make a billboard mesh type. That will allow me to just make simple pictures for use as models – especially for powerups: health and so on. The current health model is quite bad.
The goal for version 1.0:
Have a game someone can download or put on their computer and change some simple configuration: server to connect to, player name, player type and then play. Fight other people, get frags, respawn, hit frag limit, go to next level. Chat in game.
Should work on Linux and Windows. Ideally we will be able to make optimised builds for both. Currently it works perfectly on both OS’s, I see no reason that this should change.
Theme: Ninja, pirate, monkey, robot.
Each has different abilities.
The monkey
Flies about. Default weapon: throws some object, fairly short range. Like the current ‘rocket’ weapon. Other weapons? Already have monkey head model, this will be fine.
The robot
Walks about slowly. Perhaps has some laser/sniper rifle/rail gun weapon. This shouldn’t be too hard to implement. Need a model. Can’t be too hard to make simple robot model. It can be clunky. And perhaps not Bender.
The ninja and pirate sounds harder to do, so just a robot and monkey is probably a good starting point.
Powerups
Double damage? Tri-damage? Quad-damage? Something. Health.
Not all code follows this currently. Try to make any new code you write follow this document. Old stuff can be slowly migrated over. Don’t worry too much if your code doesn’t match this, but it would be nice if at some point in the not too distant future all the code followed these guidelines.
I think a good example of these can be found in entity_manager.cpp and entity_manager.h
Classes should begin with the letter C and then use upper case for the beginning of every world in the name. No underscores should be used.
Example: CWorld, CDisplayManager
All words in the name should begin with capitals like class names.
Example: CWorld::Draw(), CDisplayManager::DrawTriangleFans()
This is perhaps the most inconsistently named thing in BuNg at this time. The original coding style used m_ at the beginning of member variables and I believe this is the way to go. I wouldn’t worry too much about spending lots of time updating current code to this style; it should be slowly moved across.
Member variables (in fact, variables in general) should use lower case and underscores where appropriate.
Examples: CWold::m_particle_system, CDisplayManager::m_display
See above.
I try to cut these down as much as possible. If you must use a global that needs to be accessible from multiple parts of BuNg it can be contained in CWorld.
I’m not sure how we should name enums. Thoughts?
This can best be illustrated with examples:
// Class
class CWorld
{
CWorld();
};
// Function
CWorld::CWorld()
{
int i;
// Code block inside function
for(i = 0; i < 10; i++) {
Log("%dn", i);
}
}
Tabs should be written to file as spaces. The indentation width used should be 4 spaces.
Yet another free for non-commercial use physics SDK. This one Epic is using for the Unreal Engine. So it can’t be too bad.
Getting the start locations out of the quake 3 levels isn’t too hard: you just need to parse the entities lump in the bsp file. You get stuff like this:
{
"origin" "1052 1432 24"
"angle" "135"
"classname" "info_player_deathmatch"
}
The info_player_deathmatch entities are the ones we want. Need to extract these and convert it into a lua script file to add the spawn locations.
The real question now is where in BuNg start locations for a level should be housed.
luabind is very cool. Just like boost::python, but for lua. It does make g++ chew through the RAM when compiling though.
I was trying to design to design our scripting interface on the C++ side and was getting quite confused when something dawned on me:
The entire point of the scripting is that it is done in script files, not in C++
I was wondering why there was so little code and how much I would need to add. I think the answer is “very little”. We’ll see though. As ever, I can just add features as I need them: what I should do now is start actually using the existing scripting system and I’ll be sure to find some stuff in it lacking.
luabind is working in BuNg now: it binds the Vector3f class at the moment. Binding it was trivial, though it didn’t seem to be documented that you need th call open(lua_State *) before doing anything or you’ll segfault.
A better statistics interface. Should have a class that can handle per frame statistics and so on. Rather than the haxor way we do stuff currently.
Along the same lines a nice way of holding debugging information would be good. Some so debugging class for storing debugging variables: the way we do the contact points in the display is naaasty.
Actors always did collision queries against the entire tree; it was still hardcoded this way. This is now fixed and everything is much nicer and happier.
I was finding collision a bit slow. So I put in some basic collision stats to see how many collisions I was getting a second:
I fire one sphere off. 2,200 collision queries a second, 1 actually returns true. This is constant when it is not moving.
I fired quite a few off and got up to 32,000 at one point. That is a lot of collision queries!
Obviously something is broken if that many can happen in the space of one frame.
I think we need a better way of storing per-frame statistics. Maybe just have a statistics singleton or something.
A progress report since the 22nd: * SCons files updated for FreeBSD properly, they also use sdl-config now * COctree has had an almost complete refactor into nicer code. It is now quite a bit more efficient and the code is a lot nicer and follows a consistent naming scheme and so on. Other code such as collision in the tree that was in in bad place (in actor.cpp) is now in the tree. * Entity manager redesigned to have entities in a vector indexed by ID. * Actor/actor collisions work. Actors are now in the octree as well as being in the vector in the entity manager.
The above was quite a bit of work, but ended up in much better code. The octree is now a low happier.
Networking is currently somewhat broken because ID assignment is not sorted out properly. Each client thinks its player is ID 0, which causes problems. Need to sort out how IDs work over networking, especially with respect to creating projectiles and so on.
NB: Subversion repository is at revision 80.
The server: * Now works properly, though there is still an issue with IDs. This needs some thought. * Has a simple ncurses interface. Very, very simple so far, but quite useful as it shows when it sends/receives packets from each client. * Works on FreeBSD: it compiles and runs on vegas. Haven’t commited changes for this yet.
I now use SCons for the building on Linux/FreeBSD. This is MUCH nicer than make. The SCons files need to be updated in a better way for FreeBSD, but that isn’t hard.
Couldn’t reproduce a slowing down/jerkyness that Jesse mentioned when the server was remote. Seems ok to me, maybe recent changes have fixed this after all.
BuNg is progressing slowly towards a 1.0 version which will be playable. There has been a fair old amount of code put into the server recently so that it now has the possibility of being much more intelligent. It is now 26+99+332+161=618 lines of code. It now uses a system driver and has an entity manager and so on. This means it will update entities and perform collisions and so on. Currently it’s knowledge isn’t used for anything, but it will be in the future.
Other stuff done over the weekend: * Bung compiles fine in windows. Solution files and precompiled libraries commited to subversion repository. (This was a reasonable amount of work in the end; mainly to get the dependencies compiling OK) One nice thing about working in Windows is TortoiseSVN; it is a VERY nice subversion client. * Bug fixes in movement, the server, level loading. * Jesse added the beginnings of a GUI framework. Console code is in there but currently not working due to there being no input code just yet. Looking good! I’ve been wanting a console for aaaggeesss. This should help debugging no end when we finally get it going. * Completely new server framework as detailed above. * Partly implemented code to allow actors in the octree. This needs more work. The octree could do with some spring cleaning also (bring on spring I say!)
After hours of work there are no new screenshots to show off. However this good work will stand us in good stead in the weeks to come as there is less and less backend code to work on…
NB: Subversion repository revision number: 59
Ok, here we go: 1. Install windows and make sure everything works on windows. Perhaps pre-compile all external libs for windows and put them in subversion under a external/win32 directory or something. 1. Update server to handle objects properly and continue updating network protocol. Pack structures, make it work in windows, consider changing the amount of times packets are sent to the server. 1. Make a basic HUD. Should shot a health bar and ammo if applicable. Different for every character type? 1. Allow ellipsoid collision detection/response? Allow the camera to be off center of the collision volume so it is near the top of the sphere. 1. Allow projectiles to collide with everything else. Consider how to implement semi-fast moving small projectiles. Incremental collision? Ray collision? 1. Put entities into a vector indexed by ID and also the octree. Octree adding will need to be as fast as possible of course, but this shouldn’t be too hard. 1. Update model system. Convert .OBJ files into a BuNg format or something and make sure the importing is less broken. Allow the converter to specify collision volume as well as texture. Use the exisitng MD3 code to allow us to load .MD3 files again. We may also want to convert these to a BuNg format. 1. Consider Cal3D (for models) again. 1. Turn sound back on. 1. Add player health and some simple “dying.” 1. Add models for all the player types, if only different MD3 files. Allow choosing of player type and have this sent over the network. 1. Add a player score list and respawning. Really need spawn locations in the level files for this. Can be hardcoded initially. 1. Add different weapon types. Laser/sniper rifle: instant ray collision. Hand-to-hand/knife that only damages a small distance right in front of the player. 1. Draw the weapon the player is carrying? Firing animation? Sounds kind of hard. 1. Allow players to chat. ‘T’ to type text in to chat. Means we need a way to input text. 1. Better handling of things falling through the floor. Current method is not the best. 1. Either fix bugs as we create them, or note them somewhere. Perhaps I should set up a bug tracking system. We’ll see if it is really necessary.
Did I forget anything? The idea is that after the above list is done, I have a playable game (though not a very good one at that stage). From there content creation and tweaking will take forefront, thought there will still be a lot of coding to do to make it better. Working on anything that is not in that list is OK, but it is not getting BuNg any nearer it’s goal.
I’d like some way of assigning who is working on what and when, and also ticking them off as they are done.
Networking is coming along. It is now possible for one player to “shoot” a sphere out and for the other players to be notified of this event. Pretty cool. The current networking infrastructure is quite nice because it is so easy to add functionality to.
Currently the server is only 294 lines of C++ code!
Soon the server will need to become somewhat more complex as it handles management for non-player entities. This is going to require quite a significant change.
Things to implement next: * Entities need to collide with each other, not just the geometry * Entities need to be notified when they collide with something (projectiles need to disappear, for example) * The server needs to handle non-player entities. Currently projectiles aren’t even assigned an ID or anything; this needs to be fixed. (Probably quite a lot of work) * The packets should really be packed sometime soon. I guess it isn’t exactly critical or anything, the networking seems to work fine at the moment.
NB: OBJ files are not quite loaded correctly still, there are slight errors in their drawing. I’m not certain that I care though, they are good enough.
Might be nice to use Lua for something other than basic config stuff in the (not so near) future.
toLua generates code to allow calling C++ code from Lua. Keeping an up to date package specification for it sounds like quite a bit of work, but it may still be what we want.
Fixed up a few more things tonight.
* Models now face the correct direction!
* New resource manager. (Breaks MD3’s for now, but the fix should be easy enough)
* You now cannot climb walls via jumping.
* Flying movement works properly now. It didn’t before because I hadn’t tested
it enough.
* Moved functionality that should never have been in entity_manager.cpp out.
Added a FindEntity(int) function that finds an entity based on id. We use
this to get a pointer to the entity in net_driver.cpp so we can then update
the entities properties from there.
* Networking changed so enet_driver.cpp only has minimal functionality. net_driver.cpp now has all the networking driver independant functionality in it while enet_driver.cpp is responsible for connecting and sending packets reliably and unreliably and receiving packets. It is fairly easy to add networking functionality now, but more thought needs to go into how it all works.
Need to think about how firing projectiles works with respect to networking. I really have no idea how to handle this. Need to think how often I should try and send packets out the networking layer. I think enet handles this itself quite well, but I don’t know for sure.
The server crashes once MAX_CLIENTS numbers of players have connected. We never re-use player slots!
Orientation of imported OBJ files is not yet sorted. The monkey and gingerbread man are oriented differently for some reason. I’m sure they should be the same… This needs more investigation.
Very basic networking seems to work. I’ve fixed up a couple of things here in testing it, but no major changes. What I need to do now is: * Make clients actually send disconnects * Make the server announce to clients that someone has disconnected * Allow for reliable packets and packets that are not player update ones * Pack the player update packet struct * Put all non enet specific functionality into another networking file. enet_driver.cpp should be very small.
Away from networking, the resource manager needs to be made useful. Need to only load static models once, for example. This is mainly refactoring and some simple code, but it is quite neccessary.
Powered by WordPress