jump to navigation

Server Test Results August 11, 2010

Posted by aknartrebna in Uncategorized.
add a comment

Yesterday, on looking at some of the Valgrind output, I discovered that I had a few memory leaks in the code.  I was freeing what I was supposed to, however it was inside an if statement, so I just added an else at the end of each if statement to run mysql_free_result().  So I ran my login/out iterator, and here are the results:

==10813== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 48 from 3)
==10813== malloc/free: in use at exit: 86,275 bytes in 25 blocks.
==10813== malloc/free: 39,991,979 allocs, 39,991,954 frees, 119,153,575,663 bytes allocated.
==10813== For counts of detected errors, rerun with: -v
==10813== searching for pointers to 25 not-freed blocks.
==10813== checked 678,324 bytes.
==10813== 28 bytes in 1 blocks are still reachable in loss record 1 of 3
==10813==    at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==10813==    by 0x400C355: (within /lib/ld-2.7.so)
==10813==    by 0x4011BA6: (within /lib/ld-2.7.so)
==10813==    by 0x400DA15: (within /lib/ld-2.7.so)
==10813==    by 0x401154D: (within /lib/ld-2.7.so)
==10813==    by 0x4466131: (within /lib/i686/cmov/libc-2.7.so)
==10813==    by 0x400DA15: (within /lib/ld-2.7.so)
==10813==    by 0x44662F4: __libc_dlopen_mode (in /lib/i686/cmov/libc-2.7.so)
==10813==    by 0x44B4DC6: pthread_cancel_init (in /lib/i686/cmov/libpthread-2.7.so)
==10813==    by 0x44B4EF0: _Unwind_ForcedUnwind (in /lib/i686/cmov/libpthread-2.7.so)
==10813==    by 0x44B2900: __pthread_unwind (in /lib/i686/cmov/libpthread-2.7.so)
==10813==    by 0x44ACA1F: pthread_exit (in /lib/i686/cmov/libpthread-2.7.so)
==10813== 24,927 bytes in 9 blocks are still reachable in loss record 2 of 3
==10813==    at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==10813==    by 0x40890DC: my_malloc (in /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x4089E2A: my_error_register (in /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x4088D0F: init_client_errs (in /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x40879C8: mysql_server_init (in /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x40AEFF9: mysql_init (in /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x804A42F: main (bfoc_server.cpp:131)
==10813== 61,320 bytes in 15 blocks are still reachable in loss record 3 of 3
==10813==    at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==10813==    by 0x4090142: my_once_alloc (in /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x40907DA: (within /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x4091169: (within /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x4091486: get_charset_by_csname (in /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x40AEDD1: mysql_init_character_set (in /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x40B0DA2: mysql_real_connect (in /usr/lib/libmysqlclient.so.15.0.0)
==10813==    by 0x804A473: main (bfoc_server.cpp:134)
==10813== LEAK SUMMARY:
==10813==    definitely lost: 0 bytes in 0 blocks.
==10813==      possibly lost: 0 bytes in 0 blocks.
==10813==    still reachable: 86,275 bytes in 25 blocks.
==10813==         suppressed: 0 bytes in 0 blocks.

real    1310m14.214s
user    16m29.950s
sys    5m45.234s

The first memory leak is prolly because instead of exiting the program properly I hit Ctrl+C; the other two are from initializing and connecting to the msyql database — which occurrs in mysql.h. I would fret over this, however it only happens once during the programs running.

25 un-free’d blocks out of almost 40 million allocs/frees is about as good as it gets 🙂  I shouldn’t have to reset the server every day or so now either, nor will I have to worry about it running on only 512MB ram.  Huzzah!

Explanation of memory leaks:  In the C family of languages, you are allowed to access your computer’s memory directly.  So, when you need a non-constant amount of memory for something like a string or a variable amount of data, you have to allocate (or in programmer’s speak, alloc) that amount of memory in order to use with the malloc() function.  When you are done, it has to be freed with the function free().  Un-free’d memory is referred to as a memory leak.  If you get to many, you can potentially run out of memory or at the very minimum take up more space in memory than what is needed, potentially slowing the computer down.  Memory leaks can easily become A Bad Thing.


Character Models loaded :) August 10, 2010

Posted by aknartrebna in Uncategorized.
add a comment

Just a quick update, won’t take long.

Last week I was able to get the character model loader to work.  I now have a textured cube that moves up and down on the screen while moving from side to side.  The up and down is done in the program and side-to-side is done via animation set in Blender.  This may not sound like much, but it’s the framework for how a real character model will walk across the screen.

Currently, I’m still in a programming mood not an art mood so I’m coding some more.  Right now I’m working on NAT traversal (i.e. getting through routers) while continuing with the code designing and figuring out how to code up the battles while keeping units from “running over” each other.  As far as big hurdles go I believe these are some of the last.  I’m also still trying to get my thoughs straight on how to do unit production, i.e. where to place the buildings (either on the map or across the bottom of the screen).

Other things that are finalized:

Formation editor — will be a grid where players can drag and drop units to make formations and launch them towards the enemy.

Design — all units will be a part of a polymorphic class (of course).  Simple designs are better, and Object Oriented approaches make that happen.  The rest of the design and details haven’t been ironed out, but that one is definite.

In Progress:

Client-side networking — NAT punch-through (being worked on now, will use UDP protocol with an encryption scheme).

Attack & movement algorithm — designing the data structures to handle attacking and makeing sure collisions do not happen.

GUI design — kinda decided on, but then again maybe not…

For more updates, follow me on twitter! @aknartrebna or look for/use the hashtag #bfoc.

Progress Update and Race Outline August 4, 2010

Posted by aknartrebna in Uncategorized.
add a comment

Good news!  I have the models loaded on the screen now! w00t! …only the model is a cube that moves from side to side, but that’s a solid beginning.  I shall do a little more work to the rocket walker and finish drawing the basic Pelladian soon.  However, I’m not working on that today since I’m in a programming mood and am now in a designing mood so I’m taking advantage of it and laying out the classes for the program.  When I get it finished/finalized, I’ll post it on here for all to see.  I also have made good progress with designing the military units.  I’m going for the different races = different ways to play strategy, where each race has different pros and cons that will be balanced out so that no race is stronger than the other.  Here are the races:

Crinikian — Very technological, but not big on science. The Crinikian forces rely on robots and projectile weapons with good armor piloted by soldiers with excellent instincts for operating machines.  There are a few Crinikiians that have mastered science and make the weapons for the military to use, which range from grenades, rockets, heavy shells, mines, and perhaps a nuke or two.

Arkonite — Many believe they have magical powers, but some thing they are just scientifically advanced — no one knows for sure as they are very secretive with their “magic” devices that can do significant damage to any enemy.  They also carry “magic” shields that can regain strength after taking damage.  There is also a pyrotechnic side to the Arkonites; they can “summon” a “fire” that can stick to the enemy and can’t be doused.

Pelladian — These alien lifeforms and uninvited guests on Planet Crinikii bring some weaponry never before seen in the known universe.  Their solid black shells and glowing eyes might be fearsome enough, but coupled with their psionic weaponry and the ability to make someone melt from inside out is enough to make anyone run for the hills.

The Game Server: Progress & Design July 25, 2010

Posted by aknartrebna in Uncategorized.
add a comment

As promised, here is the server design.  Note: this update may contain some technical jargon, but I will offer some short explanations in places.  I will not explicitly give out the protocol used for security reasons.

The Server is programmed in C in order to be as fast as possible.  The design is pretty straightforward — the listener is set up (listeners wait for incoming connections).  Once a connection is made, a thread is spawned to handle the new connection.  First, the server receives all of the incoming information via TCP and makes sure all of it is received (the amount of data sent in bytes is included in the sent data).  Then, depending on certain codes, will either be a log in, log out, find game, or end of game sequence (all of these are set up in one huge switch statement).  The database accesses occur in this section (to be more specific, all database access are preformed through the server code; whereas the clients can access the DB directly, for security reasons i’d rather this not happen).

Everything through the logins and logouts is written and tested, the rest will be finished when I’m ready to write that part of the client (or I get tired of doing graphical design).


The biggest problem I have as of right now are memory leaks coming from the mysql.h library.  After googling the results from running Valgrind (a GNU debugging tool), I discovered that I was not the only one having this problem, and will attempt to find where the leaks are in the mysql library and fix them.  Since memory leaks tie up memory for as long as the program is running, the amount of memory used by the program increases every time the MySQL database is accessed by the program and I will have to restart the program every so often (depending on server usage).  I tested the server on my laptop with 3GB RAM and was able to complete 192,000 logins and logouts.  However, my old laptop (which the server will run on) has only 512MB RAM.  Not a big issue in the near future, as I can use chronjobs (a linux program that can be set to run programs at specific times) to run a script that will reboot the program.  Besides, if this truly becomes a huge problem it may be time to move to a professional server rather than an almost 7 year old lappy with Comcast (and hopefully it will get there)!

Current progress:

I am now working on character models and will hopefully have one walking on the screen soon.  I am using the .md2 file format with the md2loader C++ library.  Hopefully the next update will include a video of this!  (Which should be soon, if I can keep myself off of projecteuler.net and Starcraft 2 coming tuesday (WOOT!), but I’m usually good about being disciplined with my gaming, thankfully).

You can also watch my progress by following me on twitter, @aknartrebna, and the hashtag #bfoc.

Hello world! June 26, 2010

Posted by aknartrebna in Uncategorized.
1 comment so far


This blog will chronicle the development process of the game Battlefields of Crinikii! I’ll post updates soon talking about the progress I’ve made thus far and the things I have learned.

This blog is intended for both the technical and non-technical audiences as I will (or when I don’t, am willing to) explain the more advanced topics.  It won’t be all programming anyway, as a good portion of time will also be spent on balancing the three different races in the game that the players will get to choose from.

Info about the game:  BFoC is a head-to-head war strategy game, i.e. will be a thinking game — tactical play along with resource management without having to micromanage the troops.  The maps are simple:  players’ bases will be at each end of a linear map with a goal of knocking down the wall that is the only defense of the base.  Players will produce troops, place them into a formation, then send them across the battlefield to take out the enemy’s troops and break down the wall. Once the health of the wall falls to zero, the game is over.

Players will be rated on a system similar to the ELO system (used by many chess federations) to help keep the matches interesting.  There will also be tournament play, however I haven’t decided on how exactly this will work yet, though it will definitely be implemented and probably in several different formats (one-two day tournaments, ongoing tournaments).

Some of my inspirations for this game are warcraft/starcraft, Swirve.com’s Utopia, Chess, and (yes, it’s true!) American Football!

So far, I have the server about 50% complete and am currently doing some character modeling (i.e. learning how to use GIMP and doing computer art).  The server is programmed in C, the game in C++/OpenGL, and character modeling & animations are done using Blender and The Gimp.

In my next post, I’ll summarize the server’s progress thus far, and how I did it.  See you soon!