Jump to content

  • Log In with Google      Sign In   
  • Create Account

Strewya

Member Since 17 Dec 2009
Offline Last Active Dec 26 2014 03:14 PM

#5198380 Minimalist Programming Environment

Posted by Strewya on 15 December 2014 - 01:03 PM

 


Seriously? That's the reason you're not using the most powerful IDE on windows?

 

And no.  I've been using Microsoft compilers since DX 7.0 and VC++ 6.0.  They are awesome.  Again, not what I was talking about.  I didn't do a very good job explaining my question.

 

Nobody said anything about compilers :) The question was about IDE, which encompasses much more than a call to the compiler with a bunch of args, which is something you'd do through a .bat file in your minimalist approach.

 

But hey, if you're aiming for something like what Casey is doing on Homemade Hero, props to you. I think he makes it look easy because it's something he did a thousand times over, and has a lot of stuff prepared from before, and has been doing it for a long time (specifically, i mean the emacs config).

 

If you simply don't like the VS editor, that's perfectly fine, but don't say it's because of the all caps menu titles. :)




#5197737 One Time per Press Events vs. Continuous Events

Posted by Strewya on 12 December 2014 - 01:58 AM


I have individual update() and draw() methods for each object, but update() is acting like react(), which now that I think about it probably would be a good idea to seperate it.

In my opinion, having an update() method on objects is not a good idea, because you can't fully update one object at a time, things should be done in a lock-step sort of way.

This is code from my logicUpdate part of the game loop:

movePlayers(*this);
updateMonsterSpawners(*this);
moveMonsters(*this);
orientMonsters(m_monsters);
checkMonsterHurtingPlayer(*this);
checkLevelup(*this);
fixupCamera(*this);
orientPlayers(m_players);
fireWeapons(*this);
updatePerks(*this);
moveBullets(m_bullets);
updateBullets(m_bullets, m_monsters);
VKillLocations locations;
killMonsters(*this, locations);
generatePickups(locations, *this);
generateSplatter(locations, *this);
checkPickups(*this);
updateBonuses(*this);
updatePickups(*this);
updateDefenseMatrix(*this);
updateTimeCapsule(*this);
checkPlayerDeath(*this);
updateGuiLabels(*this);

The 'this' pointer is the Game class that contains the lists of players, enemies, projectiles, etc, and systems like graphics, input, etc.

Much more fine grained, explicit, and flexible to changing the order of operations. And each step produces a new partial state for all objects, so i don't get any issues with mismatching states between objects during part of one objects update. I find this to be much better than a magical update() method on objects. :)

 


I was actually thinking I should probably rewrite my movement code to work with events rather than a straight key array. What can I use the flag for in that case?

The flag in my little code example should be different for every thing you need. movingLeft, movingRight, movingForward, movingBackward, movingUp, movingDown, shooting, lockpickingDoor, ....., you name it. For each continuous action you want to have in your game, make a flag for it and name it appropriately. Then set that flag as i showed in the little example. :)




#5197534 One Time per Press Events vs. Continuous Events

Posted by Strewya on 11 December 2014 - 01:59 AM

First, read this post from L.Spiro. It's a great read :)

 

The idea is that you should handle events only, and not rely on SDL_GetKeyState. With SDL_GetKeyState, you might miss some of the input the player sends if you get a short stall in your game. What i would do:

First get only the events that pertain to the frame you're calculating now.

Handle only those events, by looping over them, and setting your own flags, something like Servant does with his MoveLeft flag.

 

For continuous actions, set your flags, and do stuff by checking those flags. The flags are set on SDL_PRESSED, and reset on SDL_RELEASED.

For one-time actions, set a flag on (SDL_PRESSED && repeat == 0), and reset the flag by your handling logic, something like "if(flag) { flag=false; doTheActionForFlag(); }".




#5197113 is there a name for this type of data structure?

Posted by Strewya on 09 December 2014 - 02:53 AM

I second Apochs thoughts. The whole point of a program/application is to transform some data in a meaningful way related to that programs purpose.

 

You cannot have a program without data (usually stored in a list if you have more than one data thing) and operations/transformations on that data. Every program in existence does this, and without it it wouldn't be a program, right? So is it worth categorizing or naming something that every program does and cannot function without?




#5196647 Best way of handling enemy projectiles

Posted by Strewya on 06 December 2014 - 11:36 AM

I would handle it by having a list of projectile instances at the main game loop layer, and pass that list to a skeleton when it updates. If the skeleton decides to throw a bone, it will create a projectile instance, initialize it with the required data, such as the projectile velocity, direction, gravity scale, sprite image index, starting position, etc. (note: i would make the projectile a simple data struct, which has an updateType variable, which is used to determine if the projectile needs to arc, or move like a sine wave, etc. You could do it by making a lot of derived projectile types for the different types of projectiles, if you so prefer).

 

Then the main loop simply iterates over each projectile, updates it, checks collisions, does the proper response if collision is detected, and draws it later.

 

There is a question if the projectile needs to know who threw it (like if you need to grant experience to the thrower when the projectile kills something or play an animation on a successfull hit). In such a case, give it an entityID by which you can look up it's thrower, and do the proper behaviour.




#5196638 Blood in a top-down shooter

Posted by Strewya on 06 December 2014 - 10:59 AM

I found a solution to the incorrect coordinates :)

The code is below, if anyone is interested. Basically, the idea is to first translate the world position from (-halfSize, halfSize) to (0,1), then multiply that by the window/viewport size, and calculate the world position from that screen position. The texture dimension needs to be the same as the backbuffer in order for this to work, at least i think.

for(auto splatterPosition : splatters)
{
	splatterPosition.y = -splatterPosition.y;
	//(-halfSize, halfSize) -> (0, 2*halfSize)
	splatterPosition += game.m_playingField.halfSize();
	//(0, 2*halfSize) -> (0, 1)
	splatterPosition /= (2 * game.m_playingField.halfSize());
	//(0, 1) -> (0, windowSize)
	splatterPosition *= {(float)game.m_window->getSizeX(), (float)game.m_window->getSizeY()};
	//(0, windowSize) -> worldPos
	splatterPosition = game.m_graphicsSystem.screenToWorld(splatterPosition, game.m_camera);
	game.m_splatters.emplace_back(splatterPosition, splatterImageIndex);
}



#5195644 Jump impulse based on length of pressed jump-button in box2d

Posted by Strewya on 01 December 2014 - 01:27 AM

Box2D objects each have a gravity scale, if i remember correctly, so you could do as ferrous said.

Alternatively, you could keep a force or impulse accumulator in you object, let's call it jump_energy, and each frame you want to apply F amount of force if the jump key is down, first check if the object has any jump_energy left, by taking force_to_apply = std::min(jump_energy, F), subtract jump_energy -= force_to_apply, and do object.applyImpulse(force_to_apply). You have to fiddle with the numbers to get the right feel, but this is one way to do it.
You could do something similar, but with distance travelled as the check, or with a timer so the player can keep the jump key down for x seconds before you stop applying the jump impulse every frame.

 

Also, i seem to vaguely remember there being a problem with this if applying impulses every frame, and it's done with forces instead, but don't hold me to this, and try it both ways.




#5194136 Seven stage game (Needs general feedback)

Posted by Strewya on 22 November 2014 - 10:07 AM

Possible ideas for that could be if the enemies in one act that aren't real use the base art style from another act. This would use the existing art from the game, but still make the enemies seem out of place.

Another idea would be if you occasionally flickered these enemies, with enough subtlety so it's not too apparent they're unreal, and just frequent/seldom enough so the player doesn't notice it as soon as they see the enemy.

Another would be if the unreal enemies are very subtly blurred.

Or shifting the colors of the enemies so they look a bit off, but still believable and fitting within the act.

 

These ideas shouldn't be too taxing neither on the art designers, nor the programmers to implement, but it's up to you and your team to decide if any of these would work/fit.




#5193760 Seven stage game (Needs general feedback)

Posted by Strewya on 20 November 2014 - 03:54 AM

Yeah, I know it's a bit much. On the bright side, their lives are effectively replenished each act. I think I can just have them completely restart the act if they run out of lives and have regular deaths just go back to the last time they rested, but it's supposed to be a really harsh penalty. Either way, I have to make sure some semblance of the previous deaths remains, such as the resources you used not coming back, to make that work. And... Well, I just got two delightful ideas, a new unique encounter at the place of your death and an upgrade for whatever killed you, to keep you invested in not being killed. (Blimey that's a weird sentence.) This is a game you're supposed to be slow and methodical with, and since so much of it is procedurally generated you have to figure things out frequently as you go and you need to use caution. The strong death penalty enforces that.

Don't get me wrong, i support a strong penalty for dying to have the player try hard not to die (although, that's what the players usually aim for anyway), but restarting the entire game after dying too many times is too harsh. Your idea of restarting the act seems much more reasonable. However, keep in mind the type of player that might keep dying a lot because they're just not as good at your game as you expect them to be. This is especially important if the game is focused around telling the story and providing an emotional experience. If the game is focused more around the RPG gameplay and stealth, then it might be fine.

There already IS a range, as implied by the word "child". The age groups you have access to are nondescript and there's only two of them, and it's up to you to decide exactly how old you think the character is in either of them. But I doubt anybody is going to think the younger age group is any younger than four, maybe three if you're pushing it, or that the older age group is any older than 10, maybe 12 if they have a terrible case of delayed-onset puberty. So I guess we can call that our range here.

Also, "12-18" doesn't fit anywhere in the word "child". The word for that would be "adolescent".

You're right about the adolescent thing. It was just a remark for the age range considering the characters skill set, as it seems more realistic for an "older child" to have that skill set, in comparison to a "young child". My remark just boils down to this: are you allowing the player to input a number for the age which is then shown somewhere in the game or used by the game, or are you providing a choice of "older child" and "younger child" (or some such)? If the latter, then no problem.
If the former, then having a 4 y.o. child (or 3 if you allow the extreme) wielding swords and using them like a pro is very unrealistic, especially considering the realistic combat mechanics you described. When i mentioned an age range, i meant it as "what's the integer range of numbers you're allowing the player to input as the child's age". But if it is not input nor shown, then sure, just saying "it's a child" is enough, as it keeps the actual age completely in the players mind.

They don't tell you, no, but each of them fits the the stage's emotion. If the player doesn't understand what's happened to their character in the denial act, living out a full day there isn't too unlikely, especially since they might not notice or think about the pillar of smoke in the distance that's supposed to lead them to the end area of that act. If the player is sufficiently depressed in stage 4 when they find out there's nothing there at the place they had to go to in this act, they might just decide to lay down and die there, or look around the end area, trying to find the point of going there, long enough it kills them.

Fair enough, if you think the player will accidentally bump into the hidden objectives. Do keep in mind what i mentioned about what the focus of the game is on. If you focus the game on the RPG/stealth gameplay, the story might be lost on the player in these lengthy periods between seeing the story progression. If the game should be story focused, then you might find the RPG/stealth parts to be keeping you away from teh story too much. It's really hard to say when it's just on paper, you'd need a prototype game to really assess this.


Now, about the gameplay.

The character development sounds pretty standard, so not much comment there.
The stealth mechanics sound pretty interesting and, as you say, well developed, at least on paper. I'm sure you'll have tweaks when you implement them and see them in action, but the idea seems reasonable.

The combat sounds very complex, to be honest, especially for a game that is more focused on stealth than combat. The injury system sounds like you will want to avoid combat as much as possible too, which raises a question: why is the combat so complex? If you're focusing on stealth and combat avoidance so much, i don't think making the combat so complex is going to be worth the time investment to implement as you envisioned. Of course, nobody is stopping you from doing so, but if you design and implement a really complex feature that every player will want to avoid because it's not fun or rewarding (except for potential loot from the enemy), then it's a waste of time.

The survival mechanics seems interesting on paper, but usually forcing the player to do repetitive character maintenance which doesn't provide a reward is frustrating and time consuming and nobody really likes doing it (unless it's the entire point of the game, like what Don't Starve does). I might be in the wrong here, but i just want to give you something to think about and put on a TODO list of things to playtest and evaluate.

The environment being harsh is another element which makes me a bit concerned about the players survival (and also ties into the death penalty). I'm going to guess it will just require a lot of playtesting to get right, but be cautious with making the environment as deadly an enemy as the rest of the real (or imaginary) monsters.

And the last thing, these imaginary monsters, can they kill the player, or are they as their name implies, just imaginary and not really there and therefore cannot actually harm the player? Because if they can, then is there a point in making the distinction of real and imaginary monsters?


Hope this second round of feedback helps smile.png


#5193604 Seven stage game (Needs general feedback)

Posted by Strewya on 19 November 2014 - 07:50 AM

Long post to digest.

 

You mentioned that the player would have a limited amount of lives, which, if used up, would cause the player to start the game from the start? This seems like a very strong penalty for failure, seeing this game has a story to tell. What makes you think players would be willing to play the same parts of the beggining of the game over and over again if they fail somewhere in act 3 or 4, or worse, act 5, which by your description, is pretty hard sounding? I suggest you think about that penalty.

 

Think about if you want to allow the player to freely choose the age of the child. I doubt it's realistic for a 2 year old child to be wielding any kinds of weapons, or even talking to NPCs. Maybe restrict the age within a predefined age range, like 12-18 or something, or simply preset the age and don't allow the player to change it. A wierd choice of age might break immersiveness.

 

I have a small issue with your hidden objectives, in the sense that they aren't following any logical train of thought. In one act you have to survive without dying, in another you have to die? If you instill the sense of survival in your players throught the entire game, what makes you think they will, through any kind of logical thinking, arrive to the idea that they have to die in order to get the hidden objective? Now, it might make sense, seeing as the objective is hidden (and i assume never shown), but in order to get it you're forcing the player to go against what they know about the game. If that's ok with you, then i guess it's just my issue. :) Also, be prepared for the fact that nobody will ever get the hidden objectives if they are too hard to pull off, and the players don't even know they exist (which i assume is the point of them being hidden).

 

Also, you didn't mention nothing about the actual gameplay (except some passing mention of being able to hunt, which isn't much to go on). As it stands, this is a nice idea, and would make a nice novel or cinematic, but i don't see any details of the mechanics the player would be doing for the most of the game (and that part is kinda important, seeing games are more about the interactivity than listening/watching the story).

 

I had a meeting in between writing this, so some thoughts i had might have gotten lost in the meantime. Hope you find this feedback somewhat useful. :)




#5184906 Should i prioritize CPU or Memory usage?

Posted by Strewya on 04 October 2014 - 01:58 AM

Your example isn't really appropriate, because in that case you're not prioritizing memory over CPU, you're either blocked by the size of available memory or not. The bottleneck in your example will be HDD access, not CPU.

A more appropriate example would be computing something and caching it, or computing it every frame.
For instance, you want to be able to draw a circle. You can either precompute points on the circles circumference for each angle (or half angle) using sin/cos operations and cache them in memory, or you can just compute them only when you need them inside your draw function.

Personally, i would first use what's easiest, computing them on the go when i need them, and only choose to cache them if the profiler tells me the routine is taking a long time because it's being called often.

Another factor is the platform you're building the game for. On mobile devices you're much more restriced with the amount of memory available, while on a PC you're not. The decision should never come from an assumption or a feeling, but rather from hard cold facts pulled from a profiler. Measure your performance, see how much memory you have available. If performance starts droping, see if you can optimize some algorithm, or data access patterns, or if you can cache values instead of computing them all the time.


#5179845 How do you manage object pools in your engine/game?

Posted by Strewya on 12 September 2014 - 05:32 AM

What Nemo Persona says, constantly newing and deleting objects is a bad idea if your game should be running for a longer period of time. Each new usually translates into a context switch from application/user mode into kernel mode for the OS, which then needs to allocate the requested amount of memory, and then switch back to user mode, which might take a long time depending on fragmentation and platform specifics.

 

ObjectPools are usually used to avoid new and delete for most of your use cases. You allocate a large memory buffer (either with new or malloc), and then manually hand out that memory to the rest of your application. That way you limit yourself to a low number of memory allocations, and instead only care about memory initialization (with placement new, for example).

 

The simplest way to make an ObjectPool is to use a vector for your planned type (i.e. std::vector<Ogre>), make a simple wrapper class that tracks which indices were "allocated" (more like requested to be used), and that's it. If you know for sure you will never need more than X amound of your objects, you can even just use an array (Ogre[1000]), and keep the same wrapper interface, without the user of that interface being none the wiser, except the fact that it won't be able to allocate more than 1000 Ogres.




#5174233 Staying Motivated

Posted by Strewya on 17 August 2014 - 03:17 AM

Maybe you should prototype your ideas first in some rapid prototype language or editor (Unity springs to mind). Try out different ideas every week or two. When you find a prototype game that hooks you, then start thinking about implementing it proper, either continuing in Unity (or whatever rapid proto thing you choose) or starting from scratch.

I think the biggest problem for losing motivation is when you don't have a clear vision of what you want to make, and all the implications that brings. You need to know how the game will play out from start to finish, what all the mechanics are and what systems you need to make it possible (and you know that by making a prototype first). Also, keeping the code as simplest as possible that does ONLY the things you need to complete the game helps. Creating complex systems and code will only detract you from the goal, by making you forget why you were making it in the first place.


#5174164 How do I achieve these type of Graphics?

Posted by Strewya on 16 August 2014 - 04:59 PM

By... drawing them?


#5174041 Getting Width/Height of ID3D11ShaderResourceView texture.

Posted by Strewya on 15 August 2014 - 11:12 PM

Yes, you need to release everything you're querying for. So at the end of your function you should do res->Release() and pTextureInterface->Release(). You should however first check if what you're releasing is not null. Personally, i have a inline function to do that, but you can do the exact same with a macro. However, you should also guard your code a bit, since if queryInterface fails for whatever reason, you're again dereferencing nullptr. Something like this should work:
Vec2 GraphicsSystem::getTextureDimensions(const Texture& texture) const
{
    ID3D11Resource* res = nullptr;
    m_textures[texture.m_rawTextureID]->GetResource(&res);

    ID3D11Texture2D* texture2d = nullptr;
    HRESULT hr = res->QueryInterface(&texture2d);

    Vec2 dim(0, 0);
    if( SUCCEEDED(hr) )
    {
        D3D11_TEXTURE2D_DESC desc;
	texture2d->GetDesc(&desc);
	dim.x = static_cast<float>(desc.Width);
	dim.y = static_cast<float>(desc.Height);
    }
    safeRelease(texture2d);
    safeRelease(res);
    return dim;
}





PARTNERS