Jump to content

  • Log In with Google      Sign In   
  • Create Account

jwezorek

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

#5304216 Game Timer / Game Clock

Posted by on 05 August 2016 - 09:48 AM

In the code you pasted I can't see where you calculate the floating point value for elapsed time that you pass to setPlayerTimeBasedVelocity().

I think you might be doing too much integer math, like not converting to floats early enough. For example, in your routine CalculateElapsedTimeMS() you are using a high precision timer but then convert to milliseconds at the end with an integer divide by a million, which will throw away any extra precision you were getting from System.nanoTime. Try making that routine return a double and do all your time and velocity math as floating point values everywhere.




#5304211 A Lightweight 2D Game Framework Doesn't Seem To Exist

Posted by on 05 August 2016 - 09:22 AM

Re: Corona, Godot, GameMaker
 
I think there is some confusion on what "lightweight" means in this context. It means that when you use the engine there isn't a lot of 3rd party code between you and just painting on the screen. It means that the "game framework" is close to just being a library. It is not a synonym for "simple" or "easy".
 
GameMaker, Love, Corona, and Godot(*) are not lightweight. They are ultra heavyweight. In each of these you are far away from the actual game loop. The actual game loop was written by the framework makers in C++ and compiled into an executable. Your game is a script plus your assets that is bundled with that exectuable, and loaded and run by that executable. In Love and Corona the script is in Lua, I believe. GameMaker and Godot use there own scripting languages.
 
There is a lot to be said for this approach. For example, you get the most painless cross-platform experience imaginable because the onus was mostly on the framework vendor to get cross-platform right when they wrote their executable and presumably they did a good job or you wouldnt be using their framework. Another plus is that it makes GUI game editors not only possible but easier for the framework vendors to implement than an equivalent editor would be for a lighter weight framework. So you get good GUI editors and the game making workflow becomes more visual in nature if you want it to be, which opens up the creation of simple games to people from non-programming backgrounds e.g. artists. 
 
The down side to this approach is that the you lose the freedom you get from a C++ compiler. A library gets to be heavyweight by guessing what it is you are going to want to do and implementing it for you. In the case of game engines a common thing to assume is the genre of games you will want to create -- for 2D games these frameworks are designed to create scrolling platformers. If you want to create a game that is unusual that doesn't conform to genre conventions it may be difficult or impossible. This is often the case with the little games I like to make. 
 
My current game for example involves translating tesselated shapes along the curves of a double logarithmic spiral. Could I do this in Corona? Probably, as long as Lua has all the standard higher mathematics functions, but doing so will be a pain in the ass because Corona's makers probably didn't think that users would want to interpolate affine transformations that are going to be applied to game sprites so there isn't going to be an interpolate affine transformation call in Corona Lua and there isn't going to be a "create double logarithmic spiral" call and so on. 
 
(*) - Godot actually looks like it also exposes a C++ version of the framework. Did not know this. I will have to look into Godot C++.



#5241068 Need to make app for ipad without apple products...

Posted by on 17 July 2015 - 09:39 AM

Dude, I am going to give you some very general advice that is nonetheless true: Shit like this never leads to you making money. Don't even start in on it. It is a waste of everyone's time, especially yours.

 

Just tell the guy or your brother or whoever that if they want custom software on an iPad then you need a Mac mini, an iPad Mini, and an Apple developer account, period. Don't screw around with web apps; everyone is just throwing that around because it sounds cheaper than a real custom application but it is the same amount of work and is not what they actually want.

 

They need to pay for this stuff for you, if they are not willing to invest even that little bit into this project then they are not serious about it.




#5232267 Replacing Adapter Interface with abstract classes

Posted by 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 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 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 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 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 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 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 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 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 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 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 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.






PARTNERS