My 2D Engine

Fixed my pathfinder. It was me being an idiot. RAM usage now altogether at < 20MB. Also, I fixed my pathfinder crashes as well. This thing is really shaping up.

Been spending time fixing up the math side of things. Rewrote all my rotated point code, so now things rotate fine. I’ll soon be adding onto my collision code so it is a little more accurate than just using bounding boxes.

I’ve also split up my SoundManager so that each game State can have its own independent queue of sounds. All the SoundManager has to do is hook into the queue at world load. This gives me flexibility in manipulating sounds independent of each state. So now, for example, I can Think() the sounds in one game state, pause it, and come back seamlessly where I left off.

I also implemented a test loading screen. Everything loads pretty quick, so I don’t think it’ll be seen much. Going to thread the loading in the future instead of just halting the program so I can make animated loading screen and allow interaction while loading is happening.

I’d like to post a video of what I have been doing so far, but it might be boring watching a bunch of squares moving around. I should do it anyway just to document my progress. I feel proud about what I have accomplished and I have progress immensely since I started The Man in the Cape back in 2011.

Engine work, other stuff.

Apologies for the lack of updates. Been keeping myself busy.

I’ve been writing a whole new engine for whatever game I make next. I scrapped the engine work I was doing with my City Crawler and started from scratch, since I’m making a effort to write code that I am not ashamed of. I’ve done my best to research and test different approaches to make sure that I’m taking the best route to what I am trying to accomplish.

I’m using a “Game State” based approach to handling worlds and screens. I’m in the process of writing a more complete state manager, but already I can handle loading, thinking, and drawing far easier than before.

Before, I basically would have separate classes with loading() and handling() routine for the game world and each level. Screens, such as menus, were written in different classes with different routines and needed to handled differently than levels. With my state approach, EVERYTHING, worlds, screens, menus, etc. are states that have common routines defined in the state’s parent pure virtuals. I feel this keep a good interface and removes variations, thus keeping my code organized.

Within the “Game Engine”, I’ve rewritten my loop accumulator code and have finally eliminated stuttering that was apparent in The Man in the Cape, as well as everything after that I’ve used it with since. Simple problem, but I’m happy to have found a solution that I am pleased with.

For event handling, I’ve been using a patched version of Sarah Thompson’s sigslot library. It sure beats having to write a new, convoluted event system. Why reinvent the wheel?

A* Path finding works great so far. One problem I have with it at the moment is it eats up a large amount of memory, around 1 MB per path finding entity. Eventually, I’ll have to go back and optimize that.

I’ve also written a brand new collision system, which has a simple grid-based spatial map backend. With brute force collision, I could push about 250 entities on screen before dropping below 60fps. With the new system, I can hit 800+ without problems thanks to collision checking being broken into grids.

Outside of that, I pushed an update to my SFML/PHYSICSFS texturemanager. If you use it, make sure you grab the update as it fixes some memory cleanup issues.

The Man in the Cape is now $.99.

http://www.themaninthecape.com/

I think this about closes the book on The Man in the Cape. It was a hell of a ride for my first game.

I recently played with moving MitC from SFML 1.6 to 2.0 to take advantage of the sprite speedups, but I put that idea away. It would require a complete rewrite of the game because of the updated API. Given the game runs well on lower end systems, there’s really no point. So, MitC will likely see no more updates, unless there is a massive uprising amongst the tiny MitC fanbase.

So, what’s up with the “City Crawler” I’ve been working on? Nothing, basically. I liked the engine I was building, but the game itself seemed like it was going nowhere fast, so I’ve set it aside for the time being to focus on other things.

SFML 2.0 Released

SFML 2.0 has moved from RC to final release. The main website has also been given a shiny new design.

I used SFML 1.6 on The Man in the Cape and found it to be a great media library. After I finished the game I moved onto using SFML 2.0. sfml-physfs-texturemanager, sfml-pauseableclock, and bc2-query all use some component of SFML 2.0.

If you are currently on SFML 1.6, I recommend that you begin using SFML 2.0. It’s cleaner, faster, and has really improved over 1.6 in many ways. Here’s an admittedly old changelog from Laurent, the developer of SFML. Much has changed since his log post, so expect more. In general. the 2.0 API is more robust, sprite drawing is much quicker, and it is altogether more stable than 1.6.

sfml-pausableclock

I went ahead and pushed a pausable clock for SFML 2.0 to GitHub.

sfml-pausableclock is an extension of sf::Clock for SFML 2.0 [http://www.sfml-dev.org/] that allows the instanced clock to be paused and resumed. All sfml-pausableclocks can be universally paused as well.

I created and found a lot of use with this while making The Man in the Cape. Hopefully it can help others as well.

Bad Company 2 Server Query Tool, TextureManager

https://github.com/anthnich/bc2-query

Happy enough with it at the moment. In the future, I would like to add more features, maybe more robust reporting of details. That, and make it look nicer.

The most interesting part about creating this program was figuring out the layout of the response packets when requesting the server info and the player list. The remote admin documentation yielded a lot of information on the setup, but it took some raw response dumping and a little googling to figure out every piece of the serverInfo response. My comments in bfbc2.hpp in the repo detail the exact setup of the packet for anyone who is interested.

Also, I pushed a tiny update to sfml-physfs-texturemanager to put it in its own namespace.

“Weekly” Update, Some More Coding…

Put the City Crawler aside for the week to work another pet project: a Bad Company 2 server query program.

I was recently gifted BC2 when it was sale and have been having a lot of fun with it.I’ve noticed that I’ve encountered a tiny problem.

There are servers I enjoy playing on, but sometimes they’ll be empty. While I’m waiting for someone to come on the server, I’ll go off and do something else. Sometimes I’ll idle on the server until someone shows up. I know other players who own servers and do the same thing, waiting for others to come on and play with them. All of this had got me thinking about the unneeded power draw of those combined systems idling in-game.

After giving it some thought, I decided to write a server query program that can run on the desktop and give an alert when someone is on a requested server so I can jump on and play. It’s pretty dumb and simple at the moment, and I can’t see any reason to make it more complex than it should be.

image

The server info bar turns green if there is anyone on the server. Right now, it’ll update the server information every 2 minutes. It also saves the IP Address so you don’t have to retype it next time you open it.

I’ll pound away at it a little more, then throw the source up on my GitHub page. It still crashes here and there so I have to hunt down those problems before I’m happy.

This Week in Dev: City Crawler, SFML Texture Manager

Finished the skeleton of Store NPC for my “City Crawler”. The player can now browse the NPC’s wares and sell items from his inventory. Pretty crude at the moment, but hey, it works.

Also, I’m finally getting out of the habit of using “static global classes” or singletons. I am currently moving to plain namespaces. Better late than never, I suppose.

Recently, I spent some time rewriting the TextureManager for my game, which I have put up on my brand new GitHub page. https://github.com/anthnich/sfml-physfs-texturemanager. It uses SFML 2.0 (preferably the latest nightly build maintained by eXpl0it3r) and PhysicsFS. So, you need to make sure you have the latest version of each and are all set up for those.

In SFML, sf::Textures are used to load image files. Then, sf::Textures are assigned to sf::Sprites for images manipulation, drawing, etc. Now, let’s say in your game, you need to make numerous grass sprites that use a grass.png for their image. My texture manager makes sure that you load only one instance of grass.png, which allows multiple sprites to reference it so that you don’t load your memory up with redundant grass.png textures. To use,

  1. Make sure your images are in an archive (example. grass.png is in gfx.zip).
  2. Initialize PhysicsFS and mount your archive.
  3. Create an instance of TextureManager.
  4. Create your sf::Sprite, passing TextureManager’s LoadTexture() with the path of the image in the archive as the parameter.
  5. All done. Now, Every time you pass that same path to LoadTexture(), it will return a reference to the previous created texture contained in TextureManager. No more redundant texture loads!

If you check example.cpp in the repo, you will find a working example. Hopefully it can be of some use to someone!

“City Crawler” #4

Over the last couple of weeks, I’ve been putting together more of the mechanics of my “City Crawler”.

On the RPG side, I’ve been putting together the inventory system. Now, the player can fight enemies, pick up their dropped weapons, cycle through them in the inventory, and then equip them. I’ve started work on the Trader so the player can trade in weapons and other things. I’ve also been doing my best to keep information I frequently change in external XML files, so if I change a character’s dialog I won’t be forced to recompile. So, pretty much every unique character will be able to load dialog, a weapon loadout, their potential “loot” list, and other things externally.

I’ve detailed in previous posts that I would be splitting the programming pieces of the game into “Kernels” to keep everything neat and tidy. Work in that area continues, as I have added my InventoryKernel, my WorldKernel, and my SaveKernel.

How I save the game’s progress is something that I’ve been been grappling with over the past week or so, and I think I’ve found a decent solution.

I have two pieces to the save system: The SaveData struct and the SaveKernel system. SaveData holds all of the saveable information in the game as monostate. It is updated by entities in real time and logs the progress of the gave itself. To save the game, I just run the Save() method in SaveKernel, which access SaveData, parses out the information, and saves it to a file.Effective and not too fancy.

On the subject of something outside of gamedev, I’ve been looking at open source projects to contribute to. I feel I have the confidence now to try to lend a hand and help myself gain some more experience. Should be fun!

“City Crawler” - Prototyping #3

Updates will probably continue to be scant until I get a little further along with this thing. Still loads to do.

I’ve been rewriting the design document to the game recently. It went from a cobbling of ideas to an actual formatted text document. Insane. This might be a good sign.

I have a lot of the bare mechanics planned (and some implemented), but at this point I always have that nagging feeling that these ideas are not enough to a base a game on. Everything may be fine, but I always have twinge that I am going to get the base all coded, run around in the world, and go “this is it?” Anyway, I suppose I’ll try to let things evolve as I program and allow enough space for new mechanics to emerge.

From here, I’ll just continue programming in more subsystems and entities until I have another “facet” of the game complete. Then, I’ll play test it, overanalyze it, stress over it, and then finally come to some sort of peace with it.

Now, onto some actually dev stuff.

One thing I have been implementing with my individual kernel systems are independent Heads Up Displays. HUDs were always a quirky concept for me to grasp when it comes to good coding practices.

In The Man in the Cape, I had one HUD master class that I would constantly be updating. So, inside that class, I would have different “paths” to rendering different parts of the HUD, which made the thing pretty clunky. In this prototype, I have been writing in a separate HUD systems for any manager or kernel that needs to draw a screen elements, which is far more flexible. This also means I can draw different HUDs together without worrying about the world view, screen resolution, etc. I probably should have learned this from the get-go, but what can you do.

Top