• 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.

thePyro_13

Members
  • Content count

    64
  • Joined

  • Last visited

Community Reputation

688 Good

About thePyro_13

  • Rank
    Member
  1. You could do this by combining Universal References with std::forward if you don't mind adding templates into the mix.   I haven't tested it but something like this should work: template<class VectorT> void Function(VectorT&& vData) { m_vData = std::forward(vData); } If universal references work the way i understand them too, then it should accept both kinds of references, and forward to the assignment operator preserving the reference type.   You could add a static_assert with a is_vector type_trait style check to make sure you get a clean error message rather than the template type mismatch if you pass the incorrect type.   If you'd prefer not to have templates then i'd go with the multiple functions with overloads. it's cleaner for calling code: object.Function(vDataFromSomewhere); // reference will copy data object.Function(std::move(vDataFromSomewhere)); // move will move data
  2. Many of my gameplay experiments have no real art. I often open paint.net and create a few coloured rectangles of appropriate sizes, and start added descriptive text to the image if neccisary.   You can do the same with 3d, just open a basic 3d editor, make a rectangle around the size of the object you want to represent and save it. The art doesn't need to be intuitive or descriptive for such early work in a potential project and can be easily replaced later once the general gameplay is impressive enough to attract an artist, or to justify hiring one.   You can can also look around royalty free sprite or 3d model websites for content that you can use as more descriptive and appealing placeholder; even if it doesn't directly suit your theme or art style.   Starting a big passion project is fine, so long as you understand that it will take a long time before it becomes something that will be impressive; and that you understand that as you improve and learn more about game design or programming you will likely want to redo a lot of your work(which can be discouraging for some people, as it will feel like the project is just treading water for a long time(years), before you have the skills needed to make any real progress). In forums, a lot of people don't seem experienced enough to recognise this off the bat(or their posts don't directly demonstrate this experiance), so planning such a large project can be detrimental in the long run if they just end up discouraged and put off due to a lack of tangible progress; thus the common replies advising a different mind set/path.   I don't have any advice about an engine for you, most engines you find should be able to do what you want(with a bit of work, very few will support what you want off the bat unless you choose to make a mod rather than a separate application). It'll be more about finding an engine that you can learn quickly and understand well, it's just a tool after all.
  3. I've been implementing a Entity Component System and have found it to be very clean and easy to control. Entity's store data. Controllers are attached to entities and add or alter the entities data(usually after reading it) they also handle events. Observers act on data changes and fire events. I currently have an explicit controller, that takes the user input and changes the entitys state. An implicit controller that takes movement states and turns it into actual movement. An observer that watches entity movement and fires collision events. and an observer that watches entity positions and animations and sends updated data to the renderer. Such a system can require some intermediate techniques to set up, but has many advantages. Controllers and observers each only have one task, and so are very simple. Game data is cleanly split from the renderer(and both can be moved to different threads much easier).
  4. Controls, the visible interface and consistency are the things that stick out to me most. If I can't make my character do what I want, or if I find my self frustrated with the HUD, or unable to find what I want on the HUD, I'll immediately lose immersion. Other than that, immersion is all about consistency, if things behave in a consistent way then the game will be immersive, this is true of both game mechanics, and story elements. Mechanics should be consistent. If blue keys open blue doors, and I need to get though a blue door, then their better be a blue key around somewhere; if not, then the game needs to explicitly explain the inconsistency though character dialog or some other kind of notification. For example, tell me that we're not going to get though that door, of present an alternate objective that will allow passage. And Art should be consistent. IMO realism has the opposite effect toward immersion regarding this, the more realistic the game is, the more things will stick out when something is slightly less realistic(as we cannot make everything look exactly like reality).
  5. Fake fullscreen is my preferred mode. I fall back to real fullscreen if my performance is pushing it. Or sometimes go window for slower paced or casual games(so that I can read or youtube while I wait for stuff to happen ). I think that it's perfectly fine to cut support for real fullscreen. So long as you're still supporting multiple resolutions and fake fullscreen/window mode.
  6. How old is your SFML2 library? Their was a bug in the RC that caused a similar crash on exit related to the default font used by sf::Text. Explicitly providing a font may solve your crash. Another common-ish error could be coming from your global objects. The OpenGL context is created along with your sf::RenderWindow. But if one of your globals ends up creating a sf::Texture before your window, then it may cause some problems as the texture depends on the OpenGL context.
  7. I always liked this idea, my favourite [url="http://en.wikipedia.org/wiki/Trilogy_of_Error"]episode of the simpsons[/url] follows a similar structure. And provides some interesting material for this kind of scenario. Looking at it through a story-biased lens: I think the best way to do this kind of thing is to take as much advantage of it as possible. Players should be rewarded for participating in the different views, they should see and experience things unique to their character. But they should also find things that are not explained from their play through. Thus adding an additional reward for players who are playing a second or third character as they find story clues that only make sense because of their earlier playthroughs. This could even involve events where the player has to contend with the after effects of actions taken by one of the other playable characters(but they wouldn't know that one of the other characters had caused them, unless they had already finished one of the other playthroughs). And now to reverse everything I've said, A single playthrough should still feel like a whole complete story. So it should have a sense of accomplishment and should leave the player feeling like they resolved whatever story based threats were revealed to their character. Otherwise, while playing all three characters would be rewarding, playing only one would be disorienting and present an story that feels incoherent.
  8. [quote name='BeerNutts' timestamp='1340997579' post='4954044'] I suggest people look into using SFML for 2D game programming, It has a great interface, and all the 2D API's are available and are performed in HW, unlike SDL (SFML actually sits on top of OpenGL). SFML also provides other API's to control every other part of a game: Input, Windows, Audio, and networking. So, check out [url="http://sfml-dev.org"]sfml-dev.org[/url] and see if it's what you are looking for. [/quote] I'd put another vote in for SFML. It's amazing, and it's API is very intuitive. Just make sure you use the upcoming 2.0 version rather than the outdated 1.6 version. Though as an extra, I'm pretty sure the latest SDL runs on the hardware a well. So their won't be much of a performance difference between the two. Though it looks like SDL implements a C-like interface, whereas SFML implements a very OOP C++ interface.
  9. [CODE] void redNovember::inputHandle() { if(receiver.IsKeyDown(irr::KEY_ESCAPE)) showGameMenu = !showGameMenu; //invert current value, this should let you toggle between true and false by pressing esc. //menu shit if (showGameMenu == true) { SYS->showInGameMenu(); } else SYS->hideInGameMenu(); }; [/CODE] This should do it. But I don't know how the rest of your app works.
  10. Thanks for your help. I've got it working now with the scripthandle add-on. Thanks for taking your time to help me. The angelscript library is really cool.
  11. That's right, they all inherit from Entity(except the level scripts). I've declared it as shared, but I'm having trouble defining the interface. [CODE] r = ScriptEngine->RegisterObjectMethod("Area", "asIScriptObject@ CreateEntity(std::string source, int posx, int posy)", asMETHOD(Area, CreateEntity), asCALL_THISCALL); assert( r >= 0 ); [/CODE] This line throws an assert. Do I have to register to Entity type to the Script engine? And do I define the function above as returning asIScriptObject@ or Entity@(The C++ function is now returning asIScriptObject*)?
  12. Ok I've been building off the game sample, and have made good headway. Currently both the level and the entities run from scripts. I've been trying to work out a way to expose a function to the level script which returns a script object handle rather than a handle to a c++ object. Like this(TestArea.as): [CODE] #include "Entity.as" //defines the Entity angelscript class. class TestArea { TestArea(Area @obj) { // Keep the owner for later reference @self = obj; @skeleton = self.CreateEntity("entites/skeleton/skeleton.xml", 5, 10); //loads the entity data from the xml and creates it. } Area @self; Entity @skeleton; } [/CODE] Where 'CreateEntity' creates a scripted entity and places it in the entity manager associated with this TestArea class. But I'd also like to to return the script object associated with the C++ entity so that I can define additional functions and send data without having to go back through C++ land. All I have in the C++ entity is it's asIObjectType and asIScriptObject. But I'm not sure how to get the script object in a format that I can pass back to my script. Basically I want the Entity angelscript object, not the entity C++ object. Is this possible? Any help will be greatly appreciated!
  13. Thanks for your reply. That's helped me heaps. I'll reply here again if I have any trouble.
  14. I'm been playing with AngelScript for around a week or so, and having some trouble wrapping my head around how it all fits together. I'm hoping someone here can walk me through what I need to do to achieve what I want. Basically I just want the entities in my project to be controlled by a script class(one class per entity type). The entities are described by xml(lists the script file, and image files used by the entity). I think I need a single Script Engine for my entire app. Then do I need to build a module for each entity type? The entities are only different on the scripting side, they all use the same generic class on the C++ side. I've been trying to work this all out from the Game sample included in the sdk, but some of it leaves me confused. I think it's supposed to be one module per entity, yet the example registers its objects to the engine rather than the module. Do I just register all of my classes(the ones I want scripts to be able to use) to the engine for all scripts to access? Where is IController coming from? I couldn't find it in any of the script files in the game sample project or in the C++ app. Is it a generic part of AngelScript? I suspect I'll have a lot more questions as I learn more about this library, sorry in advance if all my questions get annoying.