Another shot at Kynis Assault

Alongside a little bit of my tile based stuff I have gone back to Kynis Assault!

I'm getting a bit bogged down with the tile based stuff... what I'm currently doing in it is coding a text box! How fun does that sound! Gotta be done though so that the user can add descriptions to objects within the editor. It crosses my mind that it would be faster to just code the thing in .NET then to rewrite the wheel at every turn but I've purged such thoughts for now with a on the side project -Kynis!

A screenie of a menu I'm building atm.

Just to give a jist of the art style I'm going for ;) (hint: shit) I would show in battle but theres nothing to show really. Tomorrow there will be a screen full of bullets and game UI providing I get sleep before 3am tonight...

I fixed all my memory leak problem, was as simple as freeing a specific peice of memory every game loop after it has been utilized. I'm unsure why I had the problem, I never created anything new... only overwrote... but as said, tracked it down and found a work around.

Now this little pet project isn't without some merit towards my tile based game - also as said before I am coding a text box, a part of that system is storing string data. Due to SDL_ttf's inability to seemingly comprehend any kind of newline command I built my own class to handle it, example extract below (I'm not fixing any typographical errors that happen due to copy paste its a never ending battle):

//For each letter in the string

for(int i = 0; i

{

//new letter...

numberOfLetters ++;

//Add that letter to place holder line of text

phline +=s.at(i);

//When we run out of space to add new letters to this line...

if(numberOfLetters == maxLineChar)

{

//Add the line into a string vector as a new element and reset other data, then repeat loop

stringVector->push_back(phline);

phline = "";

numberOfLetters = 0;

}

}

(edit: yup it fucked up formatting and removed a bunch of characters...)

To display the text I have to take advantage of then way things are redrawn by using the same surface to draw each line in turn (then freeing it...), but at a new x value. Problem I'm having though is that it breaks words over lines and fails to display final lines of data if they fail to make maxLineChar's value. I'll fix that tomorrow. Fruits of Labour:

I'm also using this game to get a proper prototype for my Metal Junker upgrade system (these 3 projects MUST be done by Christmas when I'm moving on to 3D games via XNA or openGL, less then 2 months!), where weapon selection, armour values and etc are represented visually on the player object. If I don't have an in-battle screenshot to show off tomorrow I'll have that feature.

Oh an I coded a screen transition, just like a screenwipe then wipe-out. Very much needed, fed up with my games just flicking from one screen to the next (they use such little resources I usually just load the entire game at the start unless I'm trying to be a smart ass to my own detriment)

To end a run down of some features in this project:

- 3 levels each with several waves and a boss at the end (the real battles tbh).

- First boss will be the boss I created in the original Kynis Assault with an extra 3rd form this time (Outer defence hull + guns, upper and lower inner Guns, and now the new power core)

- Prototyping visual upgrade system.

- 20-30 minutes of gameplay.

- Recoded my array based firing code to be vector based - no more bullet limits unless your machine has less then a couple mb of memory, in which case drop the mac and get a real computer. ;)

- Toying with the idea of kill count levels... enemies procedurally generated forever until you kill 80 of them, bound to be interesting to implement!

Optimizations + object interaction thoughts

The goal ahead of me, to have a solid framework to create 2D tilebased games gets ever closer but as I get closer the hurdles get higher.

Performance is a bit of an issue now. I can't have the game at less then 30fps on my machine, it's an old machine and SDL isn't the fastest library but that is still a very reasonable goal. Earlier today the game was sitting at 15fps.

First thing was to change to 16BPP graphics. No image quality loss on my current art assets, 5fps gained.

Now the tricky stuff, actual code optimizations and I've tracked down the main root of my troubles. Collision checking. Taking this out I gain 10fps up to 30fps now, but it is not something I can just remove.

The current system involves checking each tile every game loop (around 1000) checking if that tile is a solid object and then checking if the player is colliding with it. Yea it doesn't take a genius to see that that is a a disaster. So...

Code optimization FROM:

if((layer0->at(t).type==9)||(layer0->at(t).type==10)||(layer0->at(t).type>=16)&&(layer0->at(t).type<=23)||(layer0->at(t).type==17)||(layer0->at(t).type==18)||(layer0->at(t).type==19)||(layer0->at(t).type==20)||(layer0->at(t).type==21)||(layer0->at(t).type==22)||(layer0->at(t).type==23))

TO:

if((layer0->at(t).type==9)||(layer0->at(t).type==10)||(layer0->at(t).type>=16)&&(layer0->at(t).type<=23))

That change got my an extra 5fps, but there is still another 5 fps to claw back from it. That is what I'm working on now. I think I may have to instead look at some more backend stuff... currently I only render tiles that are on screen(ofc)... I would extend that to collision checks but when I populate with AI's that may be operating offscreen... they will need to be able to still perform these checks with these offscreen tiles. Multiple AI's will bring system to a crawl...

I need a sort of event listener, an object fires a collision call after it is hit and only then, but how to do that without first looping through them all to check if they have actually been hit... fun stuff. There is always a better way... find it I shall.

Also had to deal with a memory leak. My first ever real memory leak, I'm so proud. Didn't take me more then 15 mins to track own and kill, but to actually fix... when I can be arsed. (It was the way I was rendering text for the FPS counter)

Feature wise the game now features a more robust layer system so I can do real world interior environments. Pictures will explain.

Outside horribly drawn building (That's a roof...yes I know)

Inside horribly drawn building

Oh and yea you will also notice that I killed the art style. The game is... dunn dunn dunn... post apocalyptic. I do this too often but uninspired post apocalyptic is better then uninspired generic fantasy. I've got some good ideas that I will be implementing once game dev begins in earnest, basically a lot of the game revolves around just surviving, keeping your stats up, finding materials for the generator, building new weaponry, scavenging, befriending people and eventually getting a little player town going. Not a huge epic RPG, I'd never finish it, the game becomes more sandbox as time passes.

Last problem to talk on, actually splitting my editor and game has now actually started to become troublesome, not sure if more trouble then I would be having if I had both the same though. I need to find some way that I can get both programs to run from one file directory for some files, then their own local for others. Changing one then having to manually change the other is causing too many errors through human error.

Edit: I am also itching to have another go at Kynis Assault my side shooter with all I've learned... must must focus on task at hand! (Besides I guess I should figure out 360* aiming in C++ first... god I miss those built in flash math libraries)

Double Edit:

I've been sitting here for the last hour or two thinking hard about ways to implement game objects that can be walked up to and interacted with in some way.

Many solutions, very exciting thing to begin coding. The main concept for detection I think I am going to go with is creating an SDL_Rect object that is always positioned directly infront of the player object. This rect will do a basic boundary check with objects on a button press.

But the objects themselves, how to define what they actually are. Two solutions:

Give my tiles a new property, check tiles against my players detection SDL_Rect. This would happen only on button press so the overhead would be minimal and only existent for a single game loop (kind of what I've done on my collision detection now - checks are only made when player state is in moving, takes care of overhead until player moves...). There is a chance of some problems with this however, the players detection box will almost always be over two or more tiles. A good advantage gameplay of this is that I could apply to this everytile very easily and allow some deep examining by the player "A broken tree", "A burnt tire" etc.

The second method is to use my effects system! ;) I create a new effect and place it over any game object. Then very similar usage to above BUT being much smaller (a vector of around 20 as opposed to 1000) I could run this check every frame and therefore do some cool things, like make a lightbulb appear above the players head when they are facing something they can interact with, save the player clicking everything! Or maybe make the effect be visible as a glow in game!

Then there are a few others but this is one major edit so I'll stop. I need to try to relax, risk of burnout is possibly very high.

Slow but steady

Converting most of my array based code to vectors.

It's nice to have built in features. With arrays I have always been forced to do memory calculations to find out sizes, but not now. So that is nice, seems to be similar on the surface to some java generic collections. Why have I done this - for effects basically. I know how big a tilemap is, but when placing special effects who knows how many I may place and I don't want to have to go digging in code everytime I make a small change. So I can dynamically create and store objects now.

Well anyhow I say most of my array code, not all. Found out that vectors are a fair bit slower then standard arrays for a bunch of reasons and speed is a bit of an issue. Depending on what I'm doing on my machine the engine runs at about 25-30 fps tops. So large things like tile map data are remaining as arrays - its not like they change their size during runtime anyhow.

Which leads me on to an observation that may render the above concerns moot. The speed problem is all down to rendering and resolution. If I change from 32 bit images to 16 bit the speed almost doubles at little to no image quality cost. An on the resolution front that plays a huge factor, a single image on screen, 120 fps @ 800*600, 50fps @ 1024*768, 35 fps @ 1280*960(my games res).

So what I'm getting at with the above is... I could change my tilemap data to vectors, make the program HUGELY more flexible and save me a hella lot of coding in future when loading maps... and it might not cause a noticeable performance hit at all! Will experiment lots.

So I also got the engine into a game build perfectly up and running now and I want to show off the basics of a cool feature, my effects system from the editor view and then in the actual game view ;) Remember, just outputting data... what the game engine does with that data is up to it ;)

No they are not mixed up ;p They are off screen, that is a diff cloud placement originally placed offscreen scrolling by ;)

Edit: Blitting disasters happen ;) Quick fix and np. I also need shadows... but that's another beast.

Further update

Coming up to a month since that last post, better write something.

Lot of time spent trying out new things (XNA) and a lot of time spent going over old things, code refactoring mostly. My last post I mentioned my 2D engine, this was both a platformer engine borrowing a lot of code form my previous games, and a top town standard fare kind of thing. Additionally there was an editor, separate from this other program.

Basically what I've done now is re-write the whole thing. I had to because I had two problems.
The first one was that having a engine that could be used in two different ways was becoming messy. Secondly, the underlying 2D engine to it all was incredibly inflexible in regards to how it could grow. Transitioning from an area of one size of tiles to another, or one number of tiles to another, or of one tilesheet to another was... incredibly painful. The editor right now has been mostly rewritten with the goal of being flexible. It took me two mins to change from a 80*80 192 tilemap to a completely different 64*64 300 tilemap with the new build. The underlying tech is the same for the actual games so a large amount of this code can be dragged over.

I have decided against incorporating game logic into my editor for test-as-you-edit functionality because basically... I'm the only end-user here and also the coder, and the code becomes HORRIBLE once you start mixing shit like that together. Editor has one function - to output tile map data. How any program uses that data is up to that program.

Coding style has changed, a ton more outputting debug information for near everything, wherever I can. Additionally rather then "if fail, fail" I've put the time to set up a new system where, "if fail, default" which has solved a lot of problems.

I'm also trying to climb out of the hole many people fall in and actually code in an object orientated manner, as opposed to a sort of... object led manner.

Also taking pointers very seriously. But my god to headaches I have had because of memory errors and all kinds of crap.

Final thing, some time ago I talked about a sort of memory manager. What I've now settled with is that but in a practical manner. It makes sense to load an external font file into this but a button class on the other hand that may only ever use a certain resource alone, can have that memory to itself, no central deposit really.

Getting there ;) (Tool bar is not complete, text is just .png, but thats for tomorrow)

UPDATE: Didn't add in the text thing today, it is irrelevant at current time, implemented duel layers, more toolbar controls and streamlined the addition of new content though ;) (Unfortunately its all hardcode, I'd love to be able to add new tiles outside of the editor but really I don't think less then 5 mins to implement new tileset is excessive ;)

Update

I haven't updated this blog is forever, a big personal problem kind of... took me off balance in where I was investing my time. Update soon I hope, working on a simple 2D level editor and some openGL stuff, also my 2D game engine is nearing pimpability which is good.

Now and soon

The main purpose of this entry is just to reflect on some of what I have learnt over my last project, Kynis Assualt. Maybe my insight will be of use to you the reader.

I choose to do something that goes against my usual course of action - and what I did was think small. Small, a quick simple game. It paid off in hindsight. While I didnt think I had much to learn from such a small task the truth is I had so much to learn. This was because what I learnt was not what I expected. My previous frame of mind was "what I have to learn to do shit" which was very little in this small project. But what I did learn was "how to do shit - better"

I created the game in a true OO fashion as ppposed to... a sort of... object-led approach, which coming from flash is a very welcome change. Additionally my C++ SDL codebase at hand is now... huge. I have code classes for player objects, window managment, fps management, bullets, guns, asset loaders, renderers, background managers, UI elements, buttons and button event mangement, on and on.

Although in the end the game I made is not a game. It is a tech demo of sorts, to test many things. I'm not sure if this is how I should proceed... there is a lot of time spent in repetition when creating a game... time that could be invested into learning in new areas...

Regardless, I am coming up with my next project and I intend for this to be a complete game. It is a big one though so I also intend to have another small arcade game at hand to work on - I will not loose myself to a single massive project ever again. A year wasted before. Not again.

The new game is a pseudo real time turn based strategy game. Like Hearts of Iron. The concept, that of a futeristic submarine simulator. In a way, I intend to build a text driven game, but with a grahical overlay. My big choices right now are how deep to make the game, do I make it linear, or do I give the player freedom. Regardless of that the player will be able to recruit crew and assign them positions, upgrade their sub, manage power reserves, fight, lock down flooded segments, organize repair etc. It's like a starship commander sim, but under water. I'm rebuying Silent Hunter as I type!

My game code structure

Thought I'd just throw out to this blog my way of doing things and see if anyone who stumbles upon this could improve it, or if they like it or how they would do it or whatever. Serious newbs may even learn something, or perhaps I'm so terrible I'll be poisoning your minds, I don't know.

Game code structure is REALLY important, now I only make small games by myself but even then a clear cut idea on how im going to structure the game code is so important, else I lapse back to my flash days and the main file is doing all the work and oh god why are there no comments and etc etc. Point being, treat the code with respect and dignity. Understand that, and things go well. Until then, continue to think I'm insane.

Now naturally every game has a main file and this can become large, but the main method of that main class should be small, like super small. Keep it too as few function calls if possible, nothing more. These functions should not create anything that isn't defined in another class and still shouldn't do anymore work then calling methods, perhaps passing data to them, but as little as possible. Organize like, player_input(), logic_update() then render(). Makes these empty methods right off the bat, force yourself into good coding practise, soon will become second nature.

Now I've always considered this to be a bit like normalization, if you can split something into a smaller seperate class, do it. For example, you have an opponent who attacks you. Try and split the AI brain that commands him do stuff and the opponent object itself apart. My point is more then "program in an object orientated style" My point is "program in an object orientated style... more" because you can always do more to do more. Uhhh this is going off track.

Lastly this is something I've started to do recently, but keep a memory management class around. Global variables, textures, objects, everything, define it in a memory management class. You could possibly have several of these classes but I'm using one for the time being on small projects. This memory management class is split with methods like "load_textures" and "load_sounds()" etc. So you would instantiate and call.

MemoryManager assets;
assets.load_textures();
assets.load_tools();
assets.blitter.apply(0,0, assets.BG, assets.window.getScreen());

Something like that. Why do this, well it keeps your files, all of them, a lot cleaner by having everything defined and managed elsewhere. Downside, this file is very unique for each program, not reusable in any sense but structure. Also I think I've a problem with the passing of data like this, if I'm not mistaken the computer is creating copies, for a memory management class, that be BAD. Will tweak to referances, I dunno. Also concerned with data privacy. Anyways a diagram of what its like.

I don't know what you call that, it breaks rules and makes rules. Its ideas on paper nothing more. Its also appears to be a spaceship. Just me? Anyhow, now ya see how if you get rid of the memory manager, the main class becomes a lot busier, which we do not want. So this is the right track, kind of.

Edit:
Another thought on the memory manager, by design no class has its own memory, but this can make some things difficult, for example a level background class COULD just hold the surface memory it itself... what is the right way.... I write to teach and end up losing myself hugely.