Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


jwezorek

Member Since 10 Nov 2009
Offline Last Active Yesterday, 03:51 PM

#5232267 Replacing Adapter Interface with abstract classes

Posted by jwezorek on 01 June 2015 - 06:02 PM

To the extent that design patterns are ever useful at all, they are useful when talking about code. They give you a common vocabulary that you can expect other programmers to know covering many technical abstractions that had no official names before patterns came to prominence. In other words, when used correctly the notion of design patterns is about terminology.

But terminology is only useful if it is providing greater specificity than ordinary language more succinctly. Design patterns often don't do this. It's succinct to call some class X an adaptor, say, but you are not really saying anything. It is less succinct to say that "Class X wraps the old library and exposes the interface that the new version of the software expects" but at least that is actually saying something about class X. In other words, if you say, "Class X is an adaptor that wraps ... blah blah blah" what exactly is the word "adaptor" actually adding?

Also the whole subject seems a little confused in that in some cases patterns are sort of common themes in how algorithms interact with data structures (e.g. the visitor); in other cases they seem to be the data structures themselves (e.g. the composite), and in other cases they seem to be styles of programming (e.g. wikipedia lists RAII as a design pattern. Is RAII even meaningful in languages besides C++?)




#5232200 Replacing Adapter Interface with abstract classes

Posted by jwezorek on 01 June 2015 - 12:26 PM

Don't worry about design patterns and certainly don't worry about whether you are using one "correctly". Design patterns are an ill-defined topic that don't add much beyond some terminology that is occasionally useful when talking about code.

 

If having a class do conversion between units polymorphically helps you then do it. If it adds too much complexity then don't do it. Call it an "adapter" if you want to, or don't -- that is all "patterns" are adding.

 

Honestly I don't understand why "design patterns" haven't gone away already as a thing. Why are young people so interested in them?




#5229863 Another basic array C problem

Posted by jwezorek on 19 May 2015 - 11:53 AM

I like QtCreator and it is what I would recommend for general cross-platform if you want to use an IDE or if you are developing to Qt specifically, of course. Beyond that I still see no reason to not use Visual Studio Community Edition unless maybe you are already familiar with QtCreator for some reason but are not familiar with VS.




#5194684 The "action" systems that 2D game frameworks all now have...

Posted by jwezorek on 25 November 2014 - 04:35 PM


I used it in cocos (long ago) because I didnt find any other means to control the stuff (like animations) tightly.
I hated it, it requires a bunch of loading code to prepare the actions, and when you need to interrupt it, cancel in the middle or something, it gets even more ugly. ( I dont remember very well thou)

 

Yeah the trouble with the actions thing that I see is the following:

  1. You often need something to happen that is "an action" in a general sense but that doesn't map cleanly to a particular sprite. It needs to happen to a bunch of sprites. It needs some state to be preserved across modifications to the sprites but not across iterations of the game loop. It is something that just naturally wants to be applied to some sprites in a loop rather than to be called by each sprite.
  2. You need to perform an action on a sprite that will take a long time (in game programming terms) to complete and probably will be cancelled, interrupted, or otherwise transformed before it completes.

Now obviously both 1. and 2. can be done with actions but would you choose to do either this way, all things be equal, if a framework wasn't demanding that you have to? And further, I would say that most "actions" in the games that I write are like 1. or 2. The exceptions would be very simple cosmetic things such as this guy is taking damage so make him glow red or whatever, but very simple cosmetic things are the exception not the rule...

 

In cocos2d-x I was able to get out of the whole action thing by just scheduling an update event on the layer and then treating that like the update in a game loop. I wrote an entire game to cocos2d-x and didn't use actions at all. Basically I used cocos2d-x for the node tree, input, and sound and that was the extent to which I used the framework. I believe it will be possible to do the same thing with Sprite Kit ... I am just posting here to see if I am being stupid. I don't want to be some dude who insists on doing everything the way I have always done it, but it just looks like to me that using the actions system is going to make my code worse.




#5194631 The "action" systems that 2D game frameworks all now have...

Posted by jwezorek on 25 November 2014 - 11:21 AM

When implementing 2D games to somewhat heavy-weight 2D frameworks like Sprite Kit or Cocos2D, do you use the action system for everything or do you prefer a traditional game loop?

 

I'm currently working in Swift + Sprite Kit which is new for me. I find myself searching for documentation or sample code that implements a standard

scene->update(dt); 
scene->render()

style game loop, but then I think maybe I am just being old-fashioned and instead I should try to embrace the actions system. My problem is that the game I am working on doesn't seem like it wants to be implemented in terms of actions, but it could just be me.

 

As a little background, basically these frameworks are kind of new in the grand scheme of things, meaning before the mobile era the only "framework" most people would consider for a 2D game would be something like SDL. SDL isnt so much a framework as a hardware abstraction layer so this question wasn't really an issue. I'm just wondering what other people do besides me -- particularly people who didn't grow up writing 2D games without any kind of framework.




#5175053 So... C++14 is done :O

Posted by jwezorek on 20 August 2014 - 10:38 AM

Am I the only one that thinks that all those new features makes C++11 look and feel completely different than C++?

Seriously, that's practicality a different language, why keep calling it C++?

 

I actually feel the opposite.

 

Before C++11 there was all this cool stuff you could get by #including <algorithm> that was impossible to use without 

  1. sprinkling, often one line, free or static functions, all over the place that either use global state or use no state.
  2. use std algorithms with state using boost::function and boost::bind
  3. sprinkling weird little functor classes all over the place.
  4. use std algorithms with state using a local anonymous struct as a functor (even though this wasn't strictly speaking legal C++ VS would let you do it)

Now you just use lambdas and std::functions. What I am saying is that once <algorithm> was part of the standard library then you pretty much had to have lambdas or an equivalent., so if you are saying the lambdas don't feel like C++ then a lot of the standard library must not feel like C++ either.




#5174775 So... C++14 is done :O

Posted by jwezorek on 19 August 2014 - 11:39 AM


Take 'auto' for example - it's great when used with caution (and very very sparsely). But I saw some programmers who just decided that it would be great to use it as much as possible (even a very experienced one), regardless of minor things like code readability and type safety.

 

Using "auto" may or may not lead to less readable code (I actually don't think this is true but whatever) but it does not lead to type unsafe code, at least for any reasonable definition of "type safety". The whole point of "auto" is that it is type safe. 

 

C++ is a statically typed language. It doesn't suddenly stop being statically typed because they added a mechanism to make the compiler deduce types for you.




#5172956 what is a template from c++ intent?

Posted by jwezorek on 11 August 2014 - 05:19 PM

Neither is really correct but 2 is closer to correct; 1 sounds more like a C-style macro.

 

Basically you can think of templates as type-safe macros. This is not altogether accurate but is a good first approximation.

 

In other words both macros and templates cause code to get generated. The compiler will do some work for you filling in what you mean. However, in the case macros the way that the preprocessor does this code generation is completely braindead: it doesn't know anything about the types involved it just pastes the arguments into the macro and if what comes out is garbage then so be it.

 

In the case of templates the compiler is checking types while it is doing the code generation.




#5172133 Does the interface of every graphic adventure game suck?

Posted by jwezorek on 07 August 2014 - 03:08 PM

Some thoughts... (and a description of the Infocom interface for younger readers)

 

I've been thinking about this for a couple of days and I think the key thing that you would have to do to make a graphical game like this would be get rid of all the guessing. In a graphical game what can be done needs to be explicit.

 

When you strip away the hype of natural language processing, the Infocom interface was basically the following:

 

  1. Nouns were marked by the game. (You enter a room once and get the elaborate description, you then start getting the abbreviated description which was a list of the nouns in the room, some of which you could take and some of which were fixed to the room, but all could serve as objects in commands while in the room)
  2. There was a list of common verbs that you knew you could use: get, move, pull, push, insert, give, tie, untie, open, close, cut, destroy, burn and a few more. This list was augmented by a few unknown verbs that were game dependent.
  3. The verbs in 2. could take direct objects as well as indirect objects where applicable. Indirect objects could be entered either as proper indirect objects or via a prepositional phrase e.g. "Give the Chistmas tree monster the coconut" or "Give the coconut to the Christmas tree monster" respectively.
  4. Prepositional phrases worked for modifying some objects if, I think, the object exposed a property for a slot associated with the preposition -- I'm guessing this is how it worked internally anyway; for example in The Hitchhiker's Guide to Galaxy pretty much the whole solution to the Babel Fish puzzle involved prepositional phrases and the object model they induced "Hang dressing gown on hook (so the "hook" has an "on" slot). Cover grating with towel (the grating also has an "on" slot which <cover> <with> knows to map to). Place satchel near door. Place junk mail on satchel. 
  5. There were places in which you could issue commands in the same form to other agents e.g. "Robot, give the coconut to the Christmas tree monster" 

On 1. and 2, I would definitely consider any guessing of words required to be a negative thing. It was mitigated by the fact that after you played a few of these games you pretty much knew which verbs you could expect and relying on the need for a magical verb to solve a puzzle was considered bad form (although it happened. the life raft in Zork I was like this: you had to guess that a pile of plastic was "inflate"-able)

 

so 1. you could do in graphics in some way. 2. you could also do by way of limiting the list to very few and having some kind of uniform mechanism for engaging one of them -- something that isn't a menu though, I find the menus I've seen ugly, but also more that just an "action" button. Don't know exactly how I will do it but this seems solvable.

 

It's 3. and 4. where there really seems to be room for innovation. I think that there would need to be a visual language for the slots bound to objects that I am assuming exist invisibly to the user in infocom games. In infocom games you had to guess what you could do to and with an object. In the interface I am envisioning I think you would need to make what you can do to an object explicite via some mechanism.

 

(and 5. couldn't be done without text ... although in a 3rd person game essentially your avatar is just a special object you are interacting with that follows the commands you are entering in some way so in theory you could have more than one)




#5172067 Does the interface of every graphic adventure game suck?

Posted by jwezorek on 07 August 2014 - 10:49 AM

Do any graphics-based adventure games have an interface as rich as the pseudo natural language interface common to Infocom's games from the 1980s?
 
If not what would such a game be like?
 
... and for the purposes of keeping this question specific enough to be answerable without answers devolving into lists of games from the last couple of decades that are good, let's define "graphics-based adventure games" conservatively as the sort of direct descendants of the adventure games of the 1980s; i.e., I am not considering Assassin's Creed to be an adventure game or even L.A. Noire. However, if someone really objects to this definition then answer away and explain why I am wrong to frame the question like this.
 
Voice/speech-to-text would be an obvious thing to do, but part of me feels like it would be a cop out.
 
What I am looking for is an interface that is purely graphical but still allows puzzles deeper than the essentially verb-noun type puzzles that SCUMM type games allow. Basically, to me the SCUMM/Lucas Arts games like Monkey Island and so forth are kind of the visual equivalent of Scott Adams games or are like visually richer and 3rd person Sierra Online games, sort of 3rd person Wizard and the Princess. 
 
What I want to figure out is what the visual equivalent of Zork II would be like, or The Hitchhiker's Guide to the Galaxy. In Zork II, say, you have a puzzle where you slide a place mat under a door, insert a letter opener into a keyhole, pull the place mat back revealing that it now has a key on it, and open the door with the key. I don't see how you could represent a puzzle like that in a Maniac Mansion style game, so I am trying to come up with a 3rd person style graphics adventure game in which you could -- but maybe it isn't possible.
 



#5171423 Advice on Computational Geometry for games

Posted by jwezorek on 04 August 2014 - 09:39 AM

It's a little hard to answer without you being more specific about which computational geometry algorithms you need to use. It is a big subject.

 

Saying that you need to "tackle computational geometry" is a bit like saying you need to tackle graphics, or tackle game design, or something equally broad. I mean, it can be as easy or as hard as you want it to be depending on the requirements of what you want to do i.e. tackling graphics for a Tetris clone is different than tackling graphics for a AAA console game.

 

But even the above is not really a good analogy because videogames need graphics by definition, videogames do not need computational geometry by definition -- even procedurally generated space shooters. So what computational geometry do you need and why do you need it? Because basically you want to not to have to use a heavy-weight library like CGAL; something like that should be a last resort.

 

Anyway, yeah, I've used CGAL in the past. I did some work with the triangulation routines. It is a solid library. One thing to note is that it is not permissively licensed. CGAL is GPLed I believe with a dual proprietary license for commercial use. I don't know anything about Wykobi... (thanks for mentioning it actually...)




#5170912 STL C++: iterator issue

Posted by jwezorek on 01 August 2014 - 10:58 AM


Hi Chris, can't do that since I need to compile on XCode too...

Xcode has supported lambdas since about version 4.5, see here. However, I believe these and other C++11 features are still not enabled by default -- at least they didn't used to be.

 

Go to build settings and look for an item called "C++ Language Dialect". You need to select C++11 or greater.




#5170658 Understanding Qt At a Deeper Level

Posted by jwezorek on 31 July 2014 - 12:06 PM


Does Qt rely on some special C++ compiler, or special rules?

Qt relies on code generation. 

 

Qt applications are written to an extension of C++ and then turned into regular C++ via code generation. This happens behind the scenes if you are using QtCreator. If you are not using QtCreator you would have to explicltly initiate this code generation step yourself as a custom build step or additional call in your build script.

 

The process that does the code generation is called the "meta object compiler".




#5170617 Your Prototyping Language?

Posted by jwezorek on 31 July 2014 - 09:32 AM

I only really develop 2D abstract puzzle games, and generally what I do is prototype them by writing them with shitty graphics to Win32 using the GDI in C++. So for example, my last game looks like this on iOS (link) but started out looking like this (link). Actually the GDI version of that one doesn't look that bad because I went through the trouble of using sprites with per-pixel alpha but if you want to make things easier you can just use the regular Win32 BitBlt(...) routine and use sprites with solid white (or whatever) backgrounds for everything. 

 

I find it pretty easy to write a Win32 game if it doesn't have to look good once you have done it once because you can use the shell of the game over and over and if you need any kind of complicated GUI widget (e.g. text boxes), well, you have Win32 at your disposal.

 

I have tried  doing prototyping in PyGame but it didnt really work for me because

  1. to be honest Python slows me down: I find that I personally can write code faster in a statically-typed language because I will just like lay out all the classes based on the first principles and then start building a game with them and let the compiler work for me. You can't do this when any variable can be any type.
  2. I end up re-using a lot of the code from the prototype as is in the production version. That game above was written to iOS using cocos2d-x which is a C++ framework. My prototype was C++ + Win32. The architecture of the prototype was sufficiently modular that 75% of it, i'd say, could be re-used without changing a line, and another 10 or 15% could be massaged into equivalent cocos2d-x-based code.

Also tried prototyping in Java but this was worse than Python for me. It was basically as complicated as doing a Win32 prototype without me having a lot of background knowledge about it.

 

That last point is the key thing: I happen to be really comfortable with Win32 because I used to write desktop applications to Win32 professionally in days gone by (i.e. the 1990s) so I think the takeaway from what I am saying is that you should probably prototype in whatever language/platform/environment on which you are most familiar and on which it is possible for you to easily get a sprite on the screen.




#5070462 Binary save files

Posted by jwezorek on 17 June 2013 - 10:51 AM


Vector of classes, each with POD inside them (correct me if i'm wrong but this is just int, char, string. No pointers etc involved), and inside those classes if I want to use inherited classes how are these saved?

 

By inventing a binary file format and implementing functionality that writes a representation of your objects to this format and functionality that creates your objects from a binary file in the format you invented. There is nothing magical about this. You have functions for writing bytes and functions for reading bytes. Think about how to use these functions to store and retrieve the state you need to be persistent.

 

Say you have a vector of pointers to instances of Foobar objects, where Foobar is an abstract base class from which a concrete Foo class a concrete Bar class inherit. Say each foo and each bar contains only an integer ID. You could define a file format like this:

 

[number, n, of Foobars in vector - 4 bytes]

[ type of first Foobar object, Foo or Bar -- 1 byte]

[ id of first  Foobar object -- 4 bytes]

[ type of 2nd Foobar object-- 1 byte]

[ id of 2nd Foobar object -- 4 bytes]

...

[ type of nth Foobar object-- 1 byte]

[ id of nth Foobar object -- 4 bytes]






PARTNERS