It's almost a month since I last wrote something, work has taken up most of my time, followed by the commute to and from stockholm (about 3 hours each day).
So far so good. Might have a little time to push into my hobby projects this weekend, maybe, the board of the RPG group I am in is supposed to have a meeting with another local group on saturday so thats a few hours more gone, and as usual there will be RPGing on sunday. So maybe I just have friday. And there is a big risk that I will end up playing games rather then coding them.
Thursday 19 April 2012
Tuesday 13 March 2012
Work work work.
Just got informed that So4it want me to work for them, so I am starting on Friday. This will get in the way of my own hobby projects but it will be offset by sweet sweet cash to live on and hopefully an awesome working enviornment/experience.
Monday 12 March 2012
Long Time, no post.
It's been a while since I written anything on the blog, there are a few resons behind this. First of all I have been at a job interview and waiting for more info if I get it or not, besides that RPGing takes a lot of my time and focus as a GM.
But on to the good news, The blue stuff is working (earlier called water), but I might have mentioned that earlier. I have also fixed up the lines so the enivornemt is a bit more squiggly and random in apperence, did a lot for the feeling.
I have also started the core mechanics for builds in the game, and done some early experiments on shadows, that I am partly ok with, and partly hate. Most for the fact that I haven't added light/shadows to the background.
But enough of this for now, it's time to get back to the code!
But on to the good news, The blue stuff is working (earlier called water), but I might have mentioned that earlier. I have also fixed up the lines so the enivornemt is a bit more squiggly and random in apperence, did a lot for the feeling.
I have also started the core mechanics for builds in the game, and done some early experiments on shadows, that I am partly ok with, and partly hate. Most for the fact that I haven't added light/shadows to the background.
But enough of this for now, it's time to get back to the code!
Wednesday 29 February 2012
Liquids and Liquid Simulation.
About a week ago I think, I got the idea to implement a liquid system into my game.
Since the plan was to make the world very large, the liquid model need to be keept simple, preferably not require a lot of new memory allocations. And in all ways as fast as possible to access.
My original design,
even if it looks interesting, have some issues with liquids that by design don't mix, they would start building underwater pyramids, and from a performance standpoint it was a bit too slow.
The goal now is try to implement a liquidmodel as described from the game Clonk where rather then moving large chunks of water, you teleport water across the waterbody, since all liquids in their system won't mix with each other, you are garantued to limit the movement a lot.
So my implemenation will probably contain acid/toxic sludge, water and oil used for various parts.
Could be that some builds require water/oil but release toxic. We will see what the future brings.
Since the plan was to make the world very large, the liquid model need to be keept simple, preferably not require a lot of new memory allocations. And in all ways as fast as possible to access.
My original design,
even if it looks interesting, have some issues with liquids that by design don't mix, they would start building underwater pyramids, and from a performance standpoint it was a bit too slow.
The goal now is try to implement a liquidmodel as described from the game Clonk where rather then moving large chunks of water, you teleport water across the waterbody, since all liquids in their system won't mix with each other, you are garantued to limit the movement a lot.
So my implemenation will probably contain acid/toxic sludge, water and oil used for various parts.
Could be that some builds require water/oil but release toxic. We will see what the future brings.
Saturday 18 February 2012
Friday 17 February 2012
Tuesday 14 February 2012
Tuesday 7 February 2012
So finaly went with Box2D
Integrated box2d into the project to decrease the work time required to implement my own collision/physics system.
So far it works and the latest working iteration is on the repository now. Grab it while it's hot.
Need to fix the pixel vs meters issues that are about to arise, and also fix the issues where the entire surface of the player counts as a collision object, thus you are allowed to jump if your side or head have any contact with the world. But thats for tomorrow or the day after that.
Sunday 5 February 2012
Collision.
I am putting some collision code together.
The most important part for any platform game is to collide with the enviroment.
Since the current goal of the game is supposed to be tilebased, the collision is rectangle based. One pass determines if any of the corners of any desired collision rectangle is inside the area of any othere desired collision rectangle. The first simple check just determines if this is true or not.
After that we have the possibility of a shallow check. This allows us to do logic based on the actuall name of the object we are colliding with, like "Player", "Box" etc.
Last but not least we have a deep collision check. This allows the collisionobjects children to be tested as well, so from here we can do more indepth logic, like checking what side of a player collided with what object. If you only can jump on an enemy it would be a collision between "bottom" and "top" we would like to check, any other form of collision would result in damage to the player.
The system itself is put together now it's just testing.
After the collision integration it's time to implement the jump function so the player might do more interesting things then just falling down.
The most important part for any platform game is to collide with the enviroment.
Since the current goal of the game is supposed to be tilebased, the collision is rectangle based. One pass determines if any of the corners of any desired collision rectangle is inside the area of any othere desired collision rectangle. The first simple check just determines if this is true or not.
After that we have the possibility of a shallow check. This allows us to do logic based on the actuall name of the object we are colliding with, like "Player", "Box" etc.
Last but not least we have a deep collision check. This allows the collisionobjects children to be tested as well, so from here we can do more indepth logic, like checking what side of a player collided with what object. If you only can jump on an enemy it would be a collision between "bottom" and "top" we would like to check, any other form of collision would result in damage to the player.
The system itself is put together now it's just testing.
After the collision integration it's time to implement the jump function so the player might do more interesting things then just falling down.
Thursday 2 February 2012
To whom it concern.
So the crap is live, anyone with a svnclient can pull down the latest gathering of crappy code.
http://gameprojectgamedevse.googlecode.com/svn/trunk/
This is the mentality that will surround this code.
This code is the best there is, if you think you can make better code, prove me wrong, BY POSTING BETTER CODE! Your opinion is worth jack shit. Write better code or don't comment on the code, simple as that, so I expect a lot of comments on the code in the future and no requests to be added to any kind of commit list.
This is a work in project, and it got a goal, get things done, get things done fast, and if the mood is there we might refactor the code if anything turns out to be impossible to implement or when things work and there is simply an interest in seeing if there is another way to implement the system.
The project have no gameplay goal or main idea whats it's going to be about, except that it got some simple platform elements in there that don't work so well at the moment.
But they will, and everything will be glorious!
Take care!
//TheSpaceMan
http://gameprojectgamedevse.googlecode.com/svn/trunk/
This is the mentality that will surround this code.
This code is the best there is, if you think you can make better code, prove me wrong, BY POSTING BETTER CODE! Your opinion is worth jack shit. Write better code or don't comment on the code, simple as that, so I expect a lot of comments on the code in the future and no requests to be added to any kind of commit list.
This is a work in project, and it got a goal, get things done, get things done fast, and if the mood is there we might refactor the code if anything turns out to be impossible to implement or when things work and there is simply an interest in seeing if there is another way to implement the system.
The project have no gameplay goal or main idea whats it's going to be about, except that it got some simple platform elements in there that don't work so well at the moment.
But they will, and everything will be glorious!
Take care!
//TheSpaceMan
Smaller project.
Once again I have realized the size of my project, that it will be unresonable to get anything out to people to play in a decent way with in a year. One of the main issues have been the lack of proper debugging possibilitoes.
So even if I'll face public outcry I have downsized into a new project, it'll be a simple platformer in mario bros style, the entire project will be avaible open source for anyone who want's to poke around in it. The link will arrive as soon as I have implemented basic collision and tile loading.
So even if I'll face public outcry I have downsized into a new project, it'll be a simple platformer in mario bros style, the entire project will be avaible open source for anyone who want's to poke around in it. The link will arrive as soon as I have implemented basic collision and tile loading.
Wednesday 25 January 2012
Event Manager.
To get information between different parts of a game, you may use events and a event manager, and event is anything happening in the game, that something else might have interest of, this could be shots fired, units dying, change in score, a unit turning visible, so about anything.
The main goal is that, once something happens, you inform all with interest that it happened, and do it once, instead of a system where you for instance save all events and loop trough them for each and every unit and deciding if they are relevant, the second one is much faster to set up, but requires a lot more prestanda, and a good event system can be used and reused for anything.
So thats where I am going today, trying to get the events up and running in a good decent way.
Tuesday 24 January 2012
AI coding.
I will cover some topics topics for the unknowing, and ofcourse from my point of view and how I see it, wouldn't be fun otherwise.
First of all
AI:
Most people know that AI stands for artificial Intelligence, often called Artificial Stupidity, or in some cases "MOM!!! The computer is cheating!".
The ideal AI is made with the goal to behave like a person expects another person to behave. A quite hard task since a computer is where good a fixed states of rules, and reasoning but not so good with random behaviors or adapting to change. A person on the other hand is very good to behave randomly or eradict and most are atleast to some degree equpied to adapt to changes. Most FPS games, that are by design mostly skillbased, fast triggerfinger and good aim will make you better, are still beaten by a wellwriten AI, this is because the AI can see allways at once, it can snap it's aim to the first microsized piece of hitbox that appears, and it's aim is allways perfect.
Some will cry "I have seen the bots for CS, they sux lolollooloololoo HAX!" and yes they often do, because people want to be able to win. But people call this cheating because a human can't see all ways at once, I am not saying that the AI is looking trough walls, that would be cheating. It's more the fact that the AI might turn a full 360 degrees, register everything thats in it's field of vision and react to it. And it can probably do that, based on the engine, say atleast 30 times a second. So as field of view goes, the AI will register anything visible from it's point of view 30 times a second, I have a hard time writing this, with the screen in focus and trying to find the coke bottle on the floor at the same time. (it was in the living room)
Add on top of that the computers increadible power to calculate things in 3 dimensions, how did you think any game was represented, (one an average today I would bet over a million triangles worth of data are rendered per frame in a modern game) and an AI only need one ray, to know where to aim and shoot prefectly, some more work comes with grenades and slow moving projectiles like rockets and other things with an area effect.
So there are some decisions to take regarding to the AI, do we want it to be best at somthing, do we want it to adapt, do we need speed or strength, how much can we simplify without it being notised.
Simplification is the best friend of a AI programmer, and data that is ready to act on at decision time, the fewer things that needs to be updated, calculated and changed, the better.
In my current project since the AI is managing both your troops as well as the enemy, (the only different is how the orders are issued), makes it possible to cheat as much as I want, since no side will get an unfair advantage, but at the same time I need to make sure that it balances out with the decisions the player does get to make.Weapon layout, skills of team members etc, as well that it should looke esticaly pleasing in some way when you actually do see combat, in many cases I could just do some random rolls and be done with it, but since any point can potentialy be seen at any time it's better to do it well, and do it right.
First of all
AI:
Most people know that AI stands for artificial Intelligence, often called Artificial Stupidity, or in some cases "MOM!!! The computer is cheating!".
The ideal AI is made with the goal to behave like a person expects another person to behave. A quite hard task since a computer is where good a fixed states of rules, and reasoning but not so good with random behaviors or adapting to change. A person on the other hand is very good to behave randomly or eradict and most are atleast to some degree equpied to adapt to changes. Most FPS games, that are by design mostly skillbased, fast triggerfinger and good aim will make you better, are still beaten by a wellwriten AI, this is because the AI can see allways at once, it can snap it's aim to the first microsized piece of hitbox that appears, and it's aim is allways perfect.
Some will cry "I have seen the bots for CS, they sux lolollooloololoo HAX!" and yes they often do, because people want to be able to win. But people call this cheating because a human can't see all ways at once, I am not saying that the AI is looking trough walls, that would be cheating. It's more the fact that the AI might turn a full 360 degrees, register everything thats in it's field of vision and react to it. And it can probably do that, based on the engine, say atleast 30 times a second. So as field of view goes, the AI will register anything visible from it's point of view 30 times a second, I have a hard time writing this, with the screen in focus and trying to find the coke bottle on the floor at the same time. (it was in the living room)
Add on top of that the computers increadible power to calculate things in 3 dimensions, how did you think any game was represented, (one an average today I would bet over a million triangles worth of data are rendered per frame in a modern game) and an AI only need one ray, to know where to aim and shoot prefectly, some more work comes with grenades and slow moving projectiles like rockets and other things with an area effect.
So there are some decisions to take regarding to the AI, do we want it to be best at somthing, do we want it to adapt, do we need speed or strength, how much can we simplify without it being notised.
Simplification is the best friend of a AI programmer, and data that is ready to act on at decision time, the fewer things that needs to be updated, calculated and changed, the better.
In my current project since the AI is managing both your troops as well as the enemy, (the only different is how the orders are issued), makes it possible to cheat as much as I want, since no side will get an unfair advantage, but at the same time I need to make sure that it balances out with the decisions the player does get to make.Weapon layout, skills of team members etc, as well that it should looke esticaly pleasing in some way when you actually do see combat, in many cases I could just do some random rolls and be done with it, but since any point can potentialy be seen at any time it's better to do it well, and do it right.
Current Project.
My current project is a Agent based RTS, where you give orders but don't control the troops, feedback from the enivorment is provided from your troops when they return, if they return.
Now most people are thinking "if I only gett feedback when my troops return, what will I do when they are away?", well your base of operation will allways have a realtime feed, and all units moving in it's range will be visible (if they are friendly, or if they are not sneaking). Additional to that, you may request the building of outposts, as well as request construction of landlines between outposts and your main base, resulting in real time feed, or atleast slightly delayed feedback from your outposts. An outpost can be any type of building you might construct like guardtowers, forts, farms and mines. The decisions if you want to landline somthing is simply a question about cost.
Squad managment and orders becomes more important if you can't actually follow your squad in realtime. So you will have the possiblity to prioritising the layout of the teams gear, where greater armor and weapons might give you an edge in a fight, but the weight might prevent them from retreating if things go south.
The main problem being, if a unit dies, the gear drops at the units current position, meaning, if you send a highly equiped team and they are outmaned, knocked out by gas, sneaking enemies, or just in someway dies, the gear will drop at that point, worse, if no one make it back, you won't miss your team untill they miss a planed radio contact (if they had a radio) or you expected them to come back. You won't even know what prevented them from coming home. It can also be so simple that the radioguy is taken out first, and the rest of the team is pinned and can't call for backup.
The game itself might suck since it's kind of unproven ground, no controll, and no feedback without reports, but it might be intresting and require a new set of strategies.
At the moment I am working on behavior trees to get the AI working, previously I've had a hardcoded leader, and hardcoded followers, and now I try to merge them, as well as allowing them to dynamicly pick a new leader if the old one dies, or if part of the team is cut off.
So far it's going quite well, but since the tree and original behaviors are quite different, it might take some time to sort things out. First goal, to place on AI that designate himself leader and try to navigate somewhere, after that, adding two AIs and make them decide who's leader, make the leader plot a course, and the follower to follow him.
I have high hopes.
Now most people are thinking "if I only gett feedback when my troops return, what will I do when they are away?", well your base of operation will allways have a realtime feed, and all units moving in it's range will be visible (if they are friendly, or if they are not sneaking). Additional to that, you may request the building of outposts, as well as request construction of landlines between outposts and your main base, resulting in real time feed, or atleast slightly delayed feedback from your outposts. An outpost can be any type of building you might construct like guardtowers, forts, farms and mines. The decisions if you want to landline somthing is simply a question about cost.
Squad managment and orders becomes more important if you can't actually follow your squad in realtime. So you will have the possiblity to prioritising the layout of the teams gear, where greater armor and weapons might give you an edge in a fight, but the weight might prevent them from retreating if things go south.
The main problem being, if a unit dies, the gear drops at the units current position, meaning, if you send a highly equiped team and they are outmaned, knocked out by gas, sneaking enemies, or just in someway dies, the gear will drop at that point, worse, if no one make it back, you won't miss your team untill they miss a planed radio contact (if they had a radio) or you expected them to come back. You won't even know what prevented them from coming home. It can also be so simple that the radioguy is taken out first, and the rest of the team is pinned and can't call for backup.
The game itself might suck since it's kind of unproven ground, no controll, and no feedback without reports, but it might be intresting and require a new set of strategies.
At the moment I am working on behavior trees to get the AI working, previously I've had a hardcoded leader, and hardcoded followers, and now I try to merge them, as well as allowing them to dynamicly pick a new leader if the old one dies, or if part of the team is cut off.
So far it's going quite well, but since the tree and original behaviors are quite different, it might take some time to sort things out. First goal, to place on AI that designate himself leader and try to navigate somewhere, after that, adding two AIs and make them decide who's leader, make the leader plot a course, and the follower to follow him.
I have high hopes.
A New Blog.
A friend of mine got annoyed when I said that I don't have much over for twitter, he thought it was a great place for me to post updates about my projects and how development is going.
The thing is, I am seldom a person of few words, and restrictions in what I can post just pisses me of. There is nothing worse then being in the middle of telling something, and suddenly have to remove a space press after a . and squeezing words together to fit the last word you need.
Rather since people think I am spaming them on MSN, I got a blog rolling, I have tried this now and again, but it usualy ends bad, that not being said it might be a good idea "THIS" time.
First of all, the main goal is to try to post something once a week, probably in the area of game devlopment and code. But one can not tell of things turn out in the long run, so this is the first post, and will probably soon be follwed by another covering what I am currently working/pokeing on.
The thing is, I am seldom a person of few words, and restrictions in what I can post just pisses me of. There is nothing worse then being in the middle of telling something, and suddenly have to remove a space press after a . and squeezing words together to fit the last word you need.
Rather since people think I am spaming them on MSN, I got a blog rolling, I have tried this now and again, but it usualy ends bad, that not being said it might be a good idea "THIS" time.
First of all, the main goal is to try to post something once a week, probably in the area of game devlopment and code. But one can not tell of things turn out in the long run, so this is the first post, and will probably soon be follwed by another covering what I am currently working/pokeing on.
Subscribe to:
Posts (Atom)