How to serialize cocos2d hierarchy for save feature - cocos2d-iphone

I'd like to create a save game feature in my cocos2d game.
Actually it's kind of a state game, where the game engine is underlying and I built the graphics into a GameLayer (CCLayer) on top of the engine. Actually the game engine is a property of GameLayer.
It's easy to serialize the engine since it ultimately just consists of some raw values, it just takes a bit of NSCoding of all contained classes.
However recreating the state of the graphical game seems tough. I am at this moment trying to restore the state by putting things into place upon restore, however this approach is very tedious and extremely prone to mistakes, and takes a lot of time and needs even more time for testing etc. It would be easier if the cocos2d hierarchy would support NSCoding or something similar. I'm thinking I should just add NSCoding to GameLayer as well but is there no simpler way (since the hierarchy should have a finite set of possible children)?

I carried out my approach with NSCoding... after working out mistakes (some rarely used classes I forgot to NSCoding:ify), it passed testing and the app was sent off to Appstore and is now live. :-P
Kind of a pain in the ass to get this requirement late in a project...

Related

Can I make a multiplayer Phaser game using Lance?

How do I take an existing Phaser game and make it multiplayer?
Can I use the Lance library for this purpose? Both libraries control their own game objects so I don't know how to use the two frameworks together in the same game.
Disclaimer: I am one of the co-creators of Lance
Unfortunately, Phaser's 2.* architecture makes it hard to pair with Lance to make Realtime Javascript Multiplayer games.
The issue is that Phaser makes a lot of assumptions that don't hold for a multiplayer setting. For example, the rendering and game loop are tied together. The server, obviously doesn't need to render anything.
Phaser also assumes the existence of the DOM and the window object which also don't exist on the server. In addition, all of the data structures that hold the world game state objects, sprites, etc' are saved on an extended instances PIXI objects which don't make sense in a Server context. These limitations and tight-coupling aren't compatible with Lance's modular approach.
It is entirely possible to run Phaser on the server using libraries that emulate DOM and Canvas like JSDOM and Node Canvas however it does mean that there's a significant performance degradation by running PIXI on the server, and you also still have the problem of syncing PIXI data structures to contend with.
The good news is that Phaser 3.0 is an ongoing, complete rewrite of Phaser 2.0 in a much more modular approach will hopefully make it much easier to integrate with Lance. We have plans to make this integration easier ourselves in the near future.

Clojure: how to architect desktop UI

I'm trying to design a desktop UI for schematics, layout, drawing stuff. Just looking for high level advice from actual software designers.
Assuming an in-memory "database", (clojure map of arbitrary depth for all user data, and possibly another one for application preferences, etc.), I'm examining how to do the model-view-controller thing on these, where the data may be rendered and modified by any one or more of:
A standalone text field that shows a single parameter, such as box width.
An "inspector" type of view that shows multiple parameters of a selected object, such as box width, height, color, checkboxes, etc.
A table/spreadsheet type of view that shows multiple parameters of multiple objects, potentially the whole database
A graphical rendering of the whole thing, such as both schematic and layout view.
Modifying any one of these should show up immediately in every other active view, both text and graphical, not after clicking "ok"... so no modal boxes allowed. If for some reason the table view, an inspector view, and a graphical rendering are all in view, dragging the corner of the box graphically should immediately show up in the text, etc.
The platform in question is JavaFX, but I'd like a clean separation between UI and everything else, so I want to avoid binding in the JFX sense, as that ties my design data very tightly to JFX Properties, increases the graininess of the model, and forces me to work outside the standard clojure functions for dealing with data, and/or deal heavily with the whole getValue/setValue world.
I'm still assuming at least some statefulness/mutability, and the use of built-in Clojure functionality such as the ability to add-watch on an atom/var/ref and let the runtime signal dependent functions.
Platform-specific interaction will rest tightly with the actual UI, such as reifying ActionListeners, and dealing with ObservableValues etc., and will attempt to minimize the reliance on things like JavaFX Property for actual application data. I'm not entertaining FRP for this.
I don't mind extending JFX interfaces or making up my own protocols to use application-specific defrecords, but I'd prefer for the application data to remain as straight Clojure data, unsullied by the platform.
The question is how to set this all up, with closest adherence to the immutable model. I see a few options:
Fine-grain: Each parameter value/primitive (ie Long, Double, Boolean, or String) is an atom, and each view which can modify the value "reaches in" as far as it needs to in the database to change the value. This could suck as there could potentially be thousands of individual values (for example points on a hand-drawn curve), and will require lots of (deref...) junk. I believe this is how JFX would want to do this, with giant arrays of Properties at the leaf nodes, etc., which feels bloated. With this approach it doesn't seem much better than just coding it up in Java/C++.
Medium-grain: Each object/record in the database is an atom of a Clojure map. The entire map is replaced when any one of its values changes. Fewer total atoms to deal with, and allows for example long arrays of straight-up numbers for various things. But this gets complicated when some objects in the database require more nesting than others.
Coarse-grain: There is just one atom: the database. Any time anything changes, the entire database is replaced, and every view needs to re-render its particular portion. This feels a bit like using a hammer to swat a fly, and a naive implementation would require everything to re-render all the time. But I still think this is the best trade off, as any primitive has a clear access path from the root node, whether it is accessed on a per-primitive level or per-record level.
I also need the ability for one data template to be instantiated many times. So for example if the user changes a symbol or shape which is used in multiple places, a single edit will apply everywhere. I believe this also requires some type of "pointer"-like behavior. I think I can store a atom to the model, then instantiate as needed, and it can work in any of the above grain models.
Any other approaches? Is trying to do a GUI editor-like tool in a functional language just stupid?
Thanks
I don't think is stupid to use a functional language to do a GUI editor-like tool. But I can't claim to have an answer to your question. Here are some links that might help you in your journey:
Stuart Sierra - Components Just Enough Structure
Chris Granger - Light Table: Explains how Light Table (source) is structured.
Chris Granger - The IDE as a Value: blog post related to the video above
Conal Elliott - Tangible Functional Programming: Using Functional Reactive Programming to create a composable UI, but his code is in Haskell.
Nathan Herzing & Chris Shea - Helping voters with Pedestal, Datomic, Om and core.async
David Nolen - Comparative Literate Programming: Shows all to use core.async to simplify UI programming in ClojureScript. The ideas here can be used in a desktop UI.
Rich Hickey - The Language of the System: Amazing talk about system programming by the creator of Clojure.
Erik Meijer has a good quote about functional vs imperative code:
...no matter whether it's Haskell, C# Java, F#, Scala, Python, PHP think about the idea of having a sea of imperative code that interacts with the outside world and in there have islands of pure code where you write your functions in a pure way.
But you have to decide how big the islands are and how big the sea is. But the answer is never that there are only islands or only sea. A good programmer knows exactly the right balance.

When to start worrying about netcode?

I'm currently working on a C++/SDL/OpenGL game. I've already made a few small games, but only local ones (no netcode). So I know how to make the engine, but I'm unsure about the netcode.
Can I firstly create the full engine for split-screen play and later on add the netcode or will this make everything complicated? Do I already have to take netcode into consideration while programming the basic game engine or is it also okay to just put it on top of the game after it runs fine on one machine?
It's a 2D shooter type game, if that matters. And no, I don't like to change my choice of programming language/window manager/api because I already implemented the bare bones of the game. I'm just curous how this issue is approached best.
In theory, all you need is a good enough design. Write enough abstract classes and BAM! you can pop out one user interface (i.e. local-only) for another one (networked). I wouldn't believe the theory, though.
It's possible to do what you want, but it involves taking into consideration all of the new issues you address when dealing with networked gameplay - syncing views for multiple users, what to do when one user drops their network link (how to detect when one user drops their network link, of course), network latency in receiving user input, handling lag on one side and not the other. Networked programming is completely different, and some of the aspects (largely ones dealing with synchronization) may impact your core engine itself. Even "just showing two views" gets a lot tougher, because you now have data on two completely different machines, and the data isn't necessarily the same.
My suggestion would be to do the opposite of what you're hoping for. Get the networking code working first with minimal graphics. In fact, console messages will be far more important than pretty graphics. You already have experience with making the graphics of other games - work the most questionable technology first. Get a good feel of all the things the networked code will ask of you, then focus on the graphics afterwards.
Normally for a network oriented game there are five concepts too keep in mind:
events
dispatcher
synchronization
rendering
simulation
Events. A game engine is a event software, that means over a state of each generic object in the game (can be a unit, GUI, etc), you do an action, that means, you call a function or do nothing.
Dispatcher take each event change and dispatch that change to another subsystem.
Synchronization means that over a change of event, all clients in network must be advised throw his dispatcher over that change, in this way all players can see the changes of other players, render and simulate same things at same time.
Rendering The render read parameters and relevant states for each object and draw in screen. For example, is you have a property for each unit named life_points, you can draw a normal unit if life_points>50 and a damage unit if life_point>0 and life_point<50 and a destroyed unit if life_point=0. Render dont make changes in objects, just draw what read from them.
Simulation read every object and perform some task taking on count states and properties, for example, if you have cero point of life, you mark the state of a unit as DEAD (for example) or change de GUI, or if a unit get close to another of a enemy team, you change the state from static to move moving close to that another unit. Plus this, here you make the physics of units, changing positions, rotations, etc etc... as you have all objects synchronized over network, everybody will be watching the same thing.
Best regards.
Add in netcode as soon as you can. If you don't do this you may have to overhaul a lot of the engine later in the dev cycle, so better to do it early.
It also depends on how complex the game is, but the same principles still stand. Best not to tack it on at the last second
Hope this helps!

The Game vs The Game Engine? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I was wondering if somebody could tell me how the game and the game engine fit into game development. Specifically what I mean is, the game engine does not actually have a game. So where I'm unclear about is basically, do game developpers build an engine, then create a new class that inherits from engine which becomes the game?
Ex:
class ShooterGame : public Engine
{
};
So basically i'm unclear on where the game code fits into the engine.
The distinction between the game and the actual game engine is architectural. The game logic is specific for one game whereas the game engine is something that can be reused. Much like an operating system provides utilities for applications the game engine does the same for the game code.
Game engines will typically have different APIs for:
Loading multimedia data like audio, textures, 3d models
Providing a game loop and firing off various events caused by the users input
Networking
Graphics rendering and various techniques to make the game look nice using lighting, particle effects or bump mapping
Audio
Artificial Intelligence
An API to allow for defining game rules, game play, and game logic
Most game developers do not write their own game engine. It would be too much work. Instead they'll reuse a game engine their company has or license one. For first person shooters, id Software, and Unreal are two popular choices.
Once they have the engine they have to start writing code to make their game. This is done using the API provided by the game engine. For example Valve makes developers use C++. If you wanted a monster you would extend off of the Entity class and define how this monster behaves in that base class.
I would recommend reading through the documentation and tutorials provided by the various game engine providers. Keep in mind some games are classified as "mods" and some as "total conversions." Typically, a mod does not change the engine of the game and the total conversion may add or remove significant features to a game engine.
Here are a few sources I would recommend:
http://developer.valvesoftware.com/wiki/SDK_Docs
http://udk.com
id Software releases their game engines as GPL after a few years. Reading through their code you'll learn a lot: ftp://ftp.idsoftware.com/idstuff/source/quake3-1.32b-source.zip. I would also recommend taking a look at Enemy Territory which was a based of quake 3 code: ftp://ftp.idsoftware.com/idstuff/source/ET-GPL.zip.
Actually, I can not tell the difference between engine and framework. It's just two different names.
What really odd is that game engine is all about client side, it seems like you do not need a server framework, whereas pure socket is enough for it.
But the reality is not like this, at least, there should be some framework like rails or django to ease your server development. Not to see game server is harder than web development in scalability, broadcast and other areas.
There is a commercial solution called smartfox server, and a new open source solution called pomelo framework, I've tried both, pomelo is much better. pomelo.netease.com is its home.
It also depends on the "level" of the Engine.
What I mean with that, is how abstract the Engine is from a certain gamestyle. There might be small things like a engine that is focused on a FPS might be built to be optimized for indoor areas, outdoor areas, that you fly at high speed. So even if a Engine might not be locked to a game, certain game types will be easier to implement certain Engines.
But as stated above, the game won't inherit the engine, it will more probably draw on it's functionality, and you will probably attach components to it's existing components. Or expand the components that are part of the engine.
class CoolDiscoLight : public Engine::Light
{
};
...
//and somewhere in the source
"CoolDiscoLight cdl = new CoolDiscoLight etc..."
EngineInstance.AddLight(cdl);
...
Even more probible is the fact that just by extending from light and overloading the correct functions the light will be accessible to a level editor etc so you won't actually create them trough the source at all.
A game engine is generally consider the code that can be pulled out and replaced with out changing the game it self.
Like has been stated already, how exactly you USE the code of an engine depends on the engine it self.
Commonly, you will instance class from the engine library and use them. The way you do this will be dictated by the engine.
Some might provide more features then other, some focus on module-ness.
Often an full game engine, will just tie together various sub engines, such as a graphics engine that handles actually drawing to screen. A physics engine for simulating your game world. a UI engine for the UI and menus. a network engine that handles entowrking things.
The 'game engine' may well have these components built in directly, or it may just be wrapping another engine/library so that you use it in a similar way to the rest of the engine.
do game developers build an engine, then create a new class that
inherits from engine which becomes the game?
It depends. Most of the time developers will make uses of existing game engines but sometimes they won't due to non-existence of wanted effects.
I have tried a number of different game engines. Most of them are behaving like this:
Defining sprites and sound elements by extending the class of it's basic entities
Defining groups for the ease of management
Defining a room or world for interaction between IO and the sprites
Program the logic in common functions like "update()" (the function will be called per frame)
Modify the entrance of the program to get into the first "room" or "world" (it can be a menu)
So a game engine is mainly do jobs of defining how the screen should display in a middle-layer, and the developer no need to worry about issues like will there be too many sprites loading outside the view-port? or When I press a key, where should the callback be located?, `Are they entity collided?" but focus on the higher level logic of the game.
Well I have been searching for game creation help and have found that an engine is the base of the entire game like the player creation is made easier as well custom graphics and physics or similar items. You also need to think of the next couple games that you plan to do and use the engine to build very little into your game which is already built for you.
If you want to learn what a game engine is, how if functions, or want to build one here is how is should go.
GLFW - For opening an OpenGL window. It's a great little C library
that opens windows on pretty much anything. Which is great because
that's one less thing to worry about.
GLEW - Managing OpenGL extensions. If you're gonna do OpenGL, there's really no getting around this one.
Lua - Scripting. Although not yet used in my game, it's pretty much the go-to language for scripting in the industry because of its
fast virtual machine implementation.
Protobuf - Managing external state. You can find a documentation it here. The short of
it is that you could use protobuf wherever you'd normally use XML.
Qt - For standard containers and string manipulation. you don't need to use the entire Qt set of libraries, only the QtCore one. This gives
you access to QList (std::vector), QHash (optimized std::map), QString
(std::string with multiple encoding support) and lots of other
goodies. Part of the reason you should go with it is because the
documentation is superb.
GLM - Math library. If you just want math in your game, this is the library for you.
freetype-gl - Text rendering. It's a very well-written library for rendering text in OpenGL, you could do
a whole lot worse.
libRocket - GUI library based on HTML and CSS. It's great when you just want a UI on the screen, but gets problematic if you want to
add animations.
Find the list here
These are great ideas for an engine just combine the libraries and build the game off of the engine you build from theses although it will take you sometime to finish if you dont have a fine team. Also I have read over this list and many others and this is the best 2d list. Also you don't need to build an engine UI because you only need the basics of the engine and build a separate project for each game. Here is how to do it right.
Engine.h
enginepart1.h
enginepart2.h
enginepart3.h (ect.)
(use .h not .cpp for engine because you can not reference engine.cpp but you can reference engine.h)
after building that
Game.cpp
gameresources.h (resources include referencing Engine.h)
gamepart1.h
gamepart2.h (etc.)
And build the engine in a fashion like this but not 100% like this would be optimal
Framework: Math, Random, Utility, Asset, Network, Window, Graphics, Audio, ...
Player: AbstractPlayer, Score, Input, Collision, Reaction, Skill, Inventory, ...
Map: AbstractMap, Area, Town, NPC, ...
Enemy: AbstractEnemy, Creep, Boss, BaseAI, FuzzyAI, ...
State: IntroScreen, MainMenu, LoginScreen, Game, PauseMenu, ...
Interface: Button, Text, InputBox, ...
Found this here
Build it like this kind of
Framework: Math, Random, Utility, Asset, Network, Window, Graphics, Audio, ...
Entities/Characters: Player, Enemy NPCs, Friendly NPCs, BaseAI ...
Map: Map/Level Editor (if you want), Map Objects (can be placed here), Special Map Features, ...
State Control: Intro Screen, Main Menu, Logic Screen, Game State, Pause Menu(s), ...
Interface: Button, Text, Input Box, ...
it often likes this
class ShooterGame
{
Engine anEngine;
public void Run();///run the world here
};
Yeah, what they said. I'd add though that game engines are usually designed for a style of game. A flight simulator needs are very different than Quake. Games like Oblivion are merging those needs together though, so this may soon not be the case.

Choosing a 3D game engine [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I want to start this as a hobby in developing a desktop game. I have found several engines, but I am not sure whether it does the initial job I am looking at.
Initially I want to do the following:
Create a figure (avatar), and let the user dress the avatar
Load the avatar in the game
In later stages, I want to develop this as a multi-player game.
What should I do?
I also recommend Ogre. Ogre can do this, it provides everything needed in regards of mesh and animation support, but not as a drop-in solution. You have to write lots of code for this to be done.
For our project we implemented something like you do. The main character and any other character can be dressed with different weapons and armor and the visuals of the character avatar change accordingly.
As a start hint for how to go about this: In your modeling tool (Blender, Maya, 3ds max, etc.) you model your avatar and all its clothes you need and rig them to the same skeleton. Then export everything individually to Ogre's mesh format.
At runtime you can then attach the clothing meshes the user chooses to the skeleton instance so that they together form the avatar. This is not hard to do via Ogre-API, but for even easier access to this you can use MeshMagick Ogre extension's meshmerge tool. It has been developed for exactly this purpose.
If you want to change other characteristics like facial features, this is possible too, as Ogre supports vertex pose animations out of the box, so you can prepare pathes for certain characteristics of the face and let the user change the face by sliders or somthing like this. (e.g like in Oblivion)
One thing to be aware regarding Ogre: It is a 3d graphics engine, not a game engine. So you can draw stuff to the screen with it and animate and light and in any way change the visuals, but it doesn't do input or physics or sound. For this you have to use other libs and integrate them. Several pre-bundled game engines based on Ogre are available though.
If you are good with C++ you should use Ogre, it's the best open-source engine, continuously been updated by it's creators, with a lot of tutorials and a very helpful community.
http://www.ogre3d.org/
It's more of a GFX engine, but it has all the prerequisites you desire.
Good luck!
No engine is likely to do this for you. What they do is generally allow you to load and render 3d models. But combining them, the way you'd need to do to "dress them" is up to you. And creating them, or letting the user do so, is ultimately up to you. The engine might offer a number of tools to make the task easier (for example, rendering the model while the user is designing it), but a game engine is not a magic "make a game" box where you just have to press a button, and your custom game comes out.
A couple of people have said Ogre3D, I'll offer up Irrlicht as an alternative.
You might want to take a look at http://www.crystalspace3d.org/ - I have to admit it was more of an exploratory matter for me, but it seemed like a pretty nice engine - with physics and scripting included. They have an project which shows the avatar walking in the spacestation-like building with very smooth camera effects.
OTOH: depending on how far you want to push this, you might find yourself recreating the SecondLife(tm)-like kind of environment. If that's a fair assumption, then you might take a look at OpenSimulator and the associated opensource viewer projects and see if this may be of interest to you - and work there with the existing team to develop the code further, rather than working on your own.
If you good with C++, I suggest the C4 Engine. From my experiences, existing game engines are either too rigid or just nothing more than a collection of libraries.
Ogre is a good way to go if you are just interested in getting something to show. As some have already stated here, Ogre is a rendering engine. There are lots of add-ons and functions to complete common tasks like Audio, Input and whatnot. This is perfectly fine if your just aiming at playing around or creating a prototype.
Should you want to start a long-term project that will be developed over a longer period of time (which would be pretty likely considering you probably being the only developer and games being complex applications), you should really start thinking about what it is that you want to do. Then, based on you're goals, look for several engines that can tackle your needs (there's always some API to accomplish XYZ). Then it's up to you how you manage your game and where you use existing libraries - you'd basically tie up your own engine according to your needs.
It get's a bit more difficult if you start looking for a real game engine in terms of "engine for all my game-dev needs". Check out the nice list of 3d game engines at devmasters (http://www.devmaster.net/engines/), you'll find lots of alpha status game engines trying to accomplish this, although you should keep in mind that support and documentation usually isn't first class in those cases.
I personally never used it, but I evaluated the open source engine Delta3D (delta3d.org) for my project and was impressed by it's cool architecture. It encapsulates a whole bunch of other quality open source frameworks for stuff like graphics (OpenSceneGraph: openscenegraph.org) or physics (ODE: ode.org). That's probably as close as you'll get to a free and flexible game engine as far as I know. It was developed at an air force university, and due to it's academic background comes with lots of detailed documentation.
If you're good with C++ you can write your own engine :P
Ogre is the best of Irrlicht and Crystalspace, and the reasoning behind that is simple - Ogre has actually been used in a production pipeline by the game industry. It actually has a lot of weight behind it, whereas Irrlicht and Crystalspace are more or less applications that don't do a lot out of the box. Crystalspace however has a branch project that implements a game engine right into Blender 3d allowing the artist to play the role of programmer without leaving the actual software.
I'm not very big on Irrlicht - there is a lot of sneakiness behind its motives. For an open source project it branches out into many different derivatives that are either complete game engines or WYSWYG editors and they find ways to lock you into paying somehow.
Ogre excels at being a graphics engine rather than a library, and it has to be compiled to individual needs. The tradeoff is you can implement Ogre into any design work flow or even create a new one. Where it takes the load off your shoulders is having to write graphics code of any kind thus making it a very slick rapid prototyping engine in its basic form.
One engine that you could try is the Torque 3D game engine www.garagegames.com which, although not being freeware, allows for out of the box usability. While the functionality that you seek in terms of being able to fully customise the character is not instantly available within the engine, if you are willing to create the models yourself it should not be too hard to add them into the game and the utilise the game engine to change the 'skins' of the avatar. One thing that I feel will set this apart from the other engines is the fact that it comes with networking functionality pre-installed (from what you have described in your question I am guessing that you are attempting to either make an RTS or MMO, and if so I wish you good luck).
While it may seem strange that the engine is based around a shooting game, there are guides witin the Torque forums that allow you to add the coding for sword based combat and other things associated with a fantasy based game (if, that is, what you are planing on making).
But anyway... good luck with your project. If you are attempting what I think you are attempting it is no easy feat. But I'm sure you know what you are doing =)
Hope this helped
If you are interested in using the Irrlicht 3D engine, you can find a number of tutorials that step you through the process of creating simple 3D applications here.
I also suggest Irrlicht. It's easier to begin with, but it does not have half of the Ogre3D support though.