• 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.
  • entries
  • comments
  • views

Save Games and Goblinson Crusoe

Sign in to follow this  
Followers 0


There is a sort of unofficial rule about save-game functionality that I learned once, long ago, but which I still have a hard time applying: from day one of coding on your game, try to maintain the ability to save and load your game at all stages.

It's a tough rule to follow because it takes discipline and work, but it can really, really save you some effort down the road. It's a rule that, unfortunately, I haven't been following with GC. I've built some pretty complex systems and frameworks, I've fleshed out combat structures, implemented some spells and skills, but I still don't have the ability to save and load.

When prototyping a game, I have the unpleasant tendency to do lots of one-off, hand-constructed code to do things like build an enemy, build a test skill, etc... I'll construct an object and manually add components, initializing those components with hard values and magic numbers, in order to test out some aspect of the game. This tends to grow the code in a hideous, spaghetti fashion where lots of so-called temporary code infests the code-base like some kind of parasite, becoming harder and harder to eradicate.

Well, I've come to a point where I need to test some things that are getting a bit complicated, so I've decided to finally start on the saving and loading. And, as expected (and as taught to me many times in the past through bad experience) it is much harder to shoehorn saving/loading later in the process than it is to just design and build the framework from the start with saving and loading in mind. As I've pondered and thought and written pages of notes and ideas, I've come up with a plan. It's involving a relatively small yet fundamental change to the underlying component system on which the whole game hangs. It's going to take a bit of work, though.

I haven't touched the existing codebase yet; I've just forked the framework, and am testing it thoroughly before I start modifying a bunch of components.

As part of the change, though, I am redoing the way I handle engine interfacing, state management, UI, etc... So far, the component system has been strictly for game objects: mobs, triggers, player, etc... In the new system, though, everything is an object, including state context, world generators, etc...

A big part of the change has been to draw up a set of rules for creating new components, rules that have to be retroactively applied to the existing ones. This includes functionality that every component must provide: specifically, streaming. A component has to be able to load all of its data from a Lua table, and has to be able to stream all of its data and state (or, at least, what it requires to reconstruct itself) to a Lua table. This, of course, is where the discipline comes in. It's easy to just whip up a new component and toss it in, but writing the code to stream it requires a bit more work and foresight.

While I test this system and start phasing it in, I won't be adding anything new gameplay-wise to GC. I'll probably continue to tinker on the graphics a bit, but no new code until theold stuff is up to date and I have phased out all of the ugly manual constructions.

Sign in to follow this  
Followers 0


That's a good rule, wish I'd heard it before I began developing my isometric game.

I had a hard time fleshing out my save/load system when starting out. Hadn't done mush lua programming at all beforehand, I suspect you are more familiar with the language than I was/am. I ended up with a buffer containing my object tables which I saved to a binary file. It works well so far but I suspect that some holes will eventually arise.

Share this comment

Link to comment
Hehe, this seems to be a hobby project rule. I got caught in the same save-game trap (not touched the topic for years, then encountered the challenge to add save/load to an existing C++/Lua game). After all it was surprisingly easy and is stable (running now for 1-2 years). I've discussed my approach with O-san over [url="http://www.gamedev.net/topic/626294-save-game/"]here[/url], providing some lua code which could be helpful. Doing this in lua is really easy, you even don't need to maintain the code because of an out-of-the-box solution which works fine for future updates. If you have an other engine part (C/C++/C#) you need to maintain the code, but from my experiences, changes in the scripting logic occurs more often.

Share this comment

Link to comment
Yeah, working in Lua is what's saving me on this one. It's nice when you can dump a save game, and have it be executable code that you can simply run to rebuild the game state. I've added version tagging to individual components, so if a component has changed since the game state was saved, it will log a warning and build the new component while attempting to reflect the old state as closely as possible. Really helps me with game versioning and keeping save files relevant across versions.

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