• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
  • entries
  • comments
  • views

A bit about my game and some slow progress

Sign in to follow this  
Followers 0


Hello Everyone,

I feel it is time for some updates on my game as I really did not say much about it. So I would like to introduce you to the concept of a game I have been wanting to make for years. The game is called Orbis. The general idea behind the game is Asteroids with a twist.
So ultimately I will be making a Asteroids clone with a few twists to spice up an old game I use to love to play at the Arcades or even on the Atari!!!!
I am not sure if I am ready to really detail out all the features quite yet as I am not sure exactly what will make it into the game just yet. So we will leave it at Asteroids with a twist for now till I flesh out more of the concepts.

I also decided to make some tool changes for the game. I decided I would stay with C++ even though after my first foray back into C++ I wanted to scream back to C. Ultimately I ditched QTCreator and MinGW. For some reason I was having issues with MinGW on Windows 8 so I decided to install Visual Studio 2013 Express Windows Desktop edition. I must say I am really impressed. I also decided to stick with SFML. To use SFML with VS2013 I needed to rebuild the library and building SFML 2.1 did not work out to well so I ended up going with the Git repo and building from there. So far so good. So here is what my new environment looks like.

  • Visual Studio 2013 Express Windows Desktop
  • CMake
  • SFML (master)
  • Git Version Control (on BitBucket)

    I am still using CMake because if I do decide to build the game on Linux for testing on my laptop CMake will save my life. So right now I use CMake to generate the Visual Studio projects and work from there. Not pretty but saves tons of headaches. Visual Studio leaves me out of my comfort zone as I am not a huge IDE fan period but we will see where this setup takes me.

    Now a bit on the progress. Not much honestly. Much of my time is taken up by school and on top of it I am trying to get back into the groove of C++ after spending a few years in the world of C. So bear with me we will get there.

    The first task I really wanted to get done was make sure SFML actually worked and it did. From there I felt the most important thing I should get out of the way is Resource Management because this is something I really can't have a game without. Sadly this was probably not the best place to start when I am trying to get my C++ groove back but none the less I think I was successful. My goal here was to put together a cache for my resources. This will be the core of ensuring all resources are properly freed up when no longer needed and will also be the core of my TextureAtlas system which is what I will be building next. I really needed this to be generic because SFML has many types of resources. So this resource cache is built to handle sf::Image, sf::Texture, sf::Font, and sf::Shader. There may be a few things but this is what I can think of off the top of my head. It will not handle music because sf::Music handles everything very differently so I will need to take a different approach for music.

    I also wanted to ensure that the memory of the cache was handled automatically. Since I am not in the world of C and the fun void* generic programming world I figured I might as well try to use some C++11.

    So my first foray into C++ after years and years of not touching it includes Templates, and some C++11. In other words AHHHH MY EYES!!!!
    Sorry for no comments but here is the code I came up with using unique_ptr for the resource which gets stored in a map. The actual key to the map will be implemented as a enum elsewhere so I can index into the cache to get what is needed. There are 4 methods. 2 load_resource methods and 2 get_resource methods there is no way to remove a resource at this point as I am not sure I need it yet for this game at least.
    One load_resource takes care of the basic loadFromFile. sf::Shader as a extra param and so can sf::Texture so the overloaded load_resource takes care of that. get_resource just returns the resource and there is a overloaded version to be called in case the cache is a const.

    Again sorry for no comments I feel the code is simple enough to not need any.#ifndef RESOURCECACHE_H#define RESOURCECAHCE_H#include #include #include #include template class ResourceCache{public: void load_resource(ResourceID id, const std::string& file); template void load_resource(ResourceID id, const std::string& file, const Parmeter& parameter); Resource& get_resource(ResourceID); const Resource& get_resource(ResourceID) const;private: std::map> resources;};template void ResourceCache::load_resource(ResourceID id, const std::string& file){ std::unique_ptr resource(new Resource()); if (!resource->loadFromFile(file)) throw std::runtime_error("ResourceCache::load_resource: Failed to load (" + file + ")"); resources.insert(std::make_pair(id, std::move(resource)));}template template void ResourceCache::load_resource(ResourceID id, const std::string& file, const Parameter& parameter){ std::unique_ptr resource(new Resource()); if (!resource->loadFromFile(file, parameter)) throw std::runtime_error("ResourceCache::load_resource: Failed to load (" + file + ")"); resources.insert(std::make_pair(id, std::move(resource)));}template Resource& ResourceCache::get_resource(ResourceID id){ auto resource = resources.find(id); return *resource->second;}template const Resource& ResourceCache::get_resource(ResourceID id) const{ auto resource = resources.find(id); return *resource->second;}#endif
    Here is the main.cpp file which I used for my functional test as well so you can see it in use.#include #include "ResourceCache.h"enum TextureID{ Background};int main(){ sf::RenderWindow window(sf::VideoMode(250, 187), "SFML Works!"); ResourceCache TextureCache; TextureCache.load_resource(TextureID::Background, "./Debug/background.png"); sf::Texture bkg = TextureCache.get_resource(TextureID::Background); sf::Sprite bkg_sprite(bkg); while (window.isOpen()) { sf::Event event; while (window.pollEvent(event)) { if (event.type == sf::Event::Closed) window.close(); } window.clear(); window.draw(bkg_sprite); window.display(); } return 0;}
    Like stated this is my first foray back into C++ so feel free to let me know if you see anything obviously wrong with the ResourceCache class. Much appreciated in advance.

    Until Next Time.

Sign in to follow this  
Followers 0


Hey. I just a question about the code. I am curious about why you chose to use a unique pointer to store the resource instead of, say, a shared pointer. It seems to me that the resource is intended to be shared so a shared pointer would seem right, and then you could provide weak pointers to those components that wanted to use the resource. In that way, if the resource cache is deleted the components are not left with dangling references.



Also, you probably want to check the results of those find() calls but you already know that :)


Share this comment

Link to comment

I did indeed think of using shared pointers but decided on unique pointers for simplicity.  The general thought I had was that each scene handles it's own resources so I will not have to pass caches around the application.  This means  each resource is unique and never actually gets copied.  So shared pointer seems a little heavy.  The other advantage is it allows me to pass out the reference to the resource instead of having to push out like you said a weak pointer because each resource by design has a 1:1 mapping to a single unique pointer.  Overall it leads to a bit of cleaner code or at least I hope.


I do understand where you are coming from in saying about the dangling refs but I don't quite see it possible because as long as a scene is alive internally it will have access to it's resources.  Using a state machine to manage the scenes should make this quite easy to attain in theory.


So ultimately by code design I am trying to modularize everything to a point where things are self contained instead of floating across the application.  My goal with that is to hope that the isolation can lead to better quality code, easier to maintain code, and easier to debug code.


Oh and yes I meant to check those find calls thanks for reminding me to actually do it lol.


Hope I answered your question in a non confusing way sometimes it is hard for me to explain what I am thinking.


Share this comment

Link to comment

neat, I was just thinking about how best to batch draw calls in SFML - It didn't occur to me that the texture can be batched, leaving the transformations intact inside a Sprite instance. Thanks!


Share this comment

Link to comment

Boy, that's kind of dangerous. If you push out a reference like that, and if at some point the resource is unloaded (and a good resource manager should allow for unloading resources as easily as loading) then the reference is invalid and a segfault is likely. The pointer type you use should reflect its usage pattern.


In my opinion, the best model to use in this case is to either use shared_ptrs all around, as suggested by jdd (which would more accurately reflect the fact that multiple entities can share a single instance of a resource), or to have the resource cache store a weak_ptr, and have the entities hold a shared_ptr. That way, the resource unloading happens "automatically" when all shared_ptrs are dropped, and the resource cache can merely check its stored weak_ptr for validity if the resource is requested again.


Either way, though, a sharing paradigm far more accurately reflects your actual usage than a unique_ptr with some unsafe references.


Share this comment

Link to comment

Two is for sure a winner.  I will look into making the code modifications to shared_ptr.  In my methodology of what I was going for I was sure unique_ptr would work.  I guess that is just my naivety with C++ and more modern C++ features at that.  Coming from a heavier background in C does not really help matters either.  Thanks for the explanation JTippetts.  Any future suggestions on code I post is just as open to scrutiny after all it is one of the best ways to learn.


Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now