Sorry your browser is not supported!

I have been learning DBP with help from the Hands on book Vol.1. I am past functions to the point where you make your first game, Hangman. I really want to learn to program with this language.

I am also very interested in learning FPSC I have a game idea and can see in my mind how it could be worked out in both. I can see the drawbacks and possibilities of each program. I think with FPSC you are kind of limited by the scripting language but with DBP I feel the world is wide open to create anything I want or need in my game.

So the problem is if I get a little bored working with one program I flip to the other. I am learning both but at a slower pace. There is really lot's of possibilities that I like with each.

The really big problem is if I am working in FPSC my mind is on DBP and vice versa and I don't think this is so good. I really think it is better to learn programming but I can't quit playing and learning FPSC.

Anyone else have this going on? and if so how do you deal with it?

Thanks
Dragonslayer

dont forget that FPSC was made in dbp,
so if you can program in dbp, u can make scripts of your own, and create own customized fps game.

i personally never even tryed fpsc and dont event want to bother my self with something "easy" like that when you know dbp.

i hope i helped you to make the right decision.

You don't need to know DBP to make the scripts for FPSC but you need to know the action script language and it is not really difficult but not that easy either. I do like that if you know DBP you can mod FPSC.

My idea for a game is an rpg based on an old school rpg game I am not really jumping on the rpb bandwagon but am a huge fan of rpg's. FPSc has the RPG mod which I had working but it slowed things down greatly. in my game I want a banking system and you have to have an inventory system create character, spells and magic, etc...

This is not in FPSC as it sits you either need the RPG mod or script them yourself. I kind of get the scripting language but would not even know where to begin scripting these systems. I am not even that far along in DBP yet and can see that code in my head and know how I would code these systems.

I may like to make an all text game. As I started really thinking about it that may not be as easy as some think. I am thinking that player movement would have to be based on a grid system, keeping track of player location, building locations etc... I have seen a lot in the forum I AM GONNA MAKE THIS OR THAT but when you really start some deep thought on it more and more stuff comes up that need to be programmed. There is no way I would give up DBP for FPSC but there is still something there that has me interested but it does take away from my DBP time LOL!!!

Dragonslayer

I agree with Sergey K.

But in the end you need to look at what you intend to do and how much time you want to spend doing it.

You can ultimately go further with DBP if you have the time and skill. However, you can get something at least livable running in FPSC a bit quicker and easier.

I understand this. It will have to be DBP but I do enjoy playing with FPSC.

Dragonslayer

I never got past basic FPSC Place and play. I just use it to check out my new model packs quickly and easily.

Dbpro is the better option in my opinion. Granted some people have created some astonishing work with FPSC and some knowhow, but for me there is nothing like taking complete control over your environment and doing the full custom job, which is where DBpro is great.

There is no harm in tinkering with both of them, you clearly like them both, use them both, so far as I understand you can import FPSC maps into dbpro projects.

I think there is a tutorial in the FPSC community guide on how to import maps from FPSC to DBP.

Why don't you build a model viewer with DBP?

You are right I do like both programs but you said it there are clear advantages to learning DBP!

Dragonslayer

That's exactly where I started, in DBC. I thought it would be cool to build a model viewer. Then I transitioned to driving that model over terrain, and then animating the model with movement.


In DBP, one of the coolest moments way back was being able to walk through a level, and see all the other characters just standing there. I created (basic) AI for the first time in one sitting without testing. To suddenly see a character following you around in the game world is awesome. It made a huge impact since I never saw it do that before and I realized I just did all myself. Now that's small potatoes, but then, the first time it was a big thing.

How are or did you learn? I am going by the hands on vol 1 DBP book some times that gets boring especially the basic stuff. I want to start building routines for a game. I am to the first game in the book, hangman which I don't really want to do but I am sure I will learn something from it.

Sometimes I just want to throw the book away and learn things I want to learn now and go back and learn the things I need to learn when I need them.

I have had in the past cubes moving around on a matrix, sprites working etc... all by just playing around. The game I am on in the book is using commands that have not even been explained yet, like screen set up etc... which I do understand already.

I am just not sure which approach is better, book chapter by chapter or just playing around. I am sure just playing around is more fun and I think when you actually get something working that you dreamed up to learn some commands it will stick with you better than if you just read it from a book. that does get boring.

Dragonslayer

Well there's a lot of different approaches.

Generally Speaking...
If this is a hobby, you want to have something working rather quickly and just revise/layer/add more things as time goes on. A more professional planned approach has it's merits but also has the risk of being too boring and losing your interest. Although you should do this to some degree.

In simple terms I started small and made thousands of revisions. When I found areas I didn't do so well in, I rewrote those areas of code.



More specifically to my case... (My Story)
I liked games like Goldeneye and GTA, and decided I wanted to make a FPS / 3D Shooter, sandbox styled game. In fact, what got me started was Heavy Metal 2000. It's like you're playing Quake but in the 3rd person.

(A long time ago...)
So I made a prototype character in Milkshape 3D. Then I tried to get it to load up in Dark Basic Classic. I thought I saw a lot of player made characters with awful wrong proportions, so I tried extra hard to make the character not look stupid.

So I got the person to load up on a blue DBC screen. Then I experimented with cycling textures, attaching different heads, and adding glued on clothing objects to make it look better than a simple flat textured person. I thought that was neat so I figured out how to make a ground matrix and texture it. Then I put the character on the matrix, and programmed in controls to move around on the matrix ground. I went into milkshape3d and made walking animations. Then In DBC I figured out how to make it play the walking animation when the character was moving and a standing animation when it was still.

I knew I didn't want to hard code everything so I also wrote editors for things like character creation, scripts, levels, items, game world entities.



Eventually I switched to DBP (also a long time ago) and things just mothballed from there where necessity took me. I always tried to plan ahead with structuring the game code. I knew this would pay off well in the end and it has.

Over time I figured out how to be more efficient. At first the game would be one room, with a couple people and really slow. I fixed a lot of things. For instance, I figured out I could add fog and hide everything behind it. That had it's drawbacks... I figured out how to hide everything outside the camera. I figured out how to designate regions in the game levels and inside the level editor dictate which areas can see each other. That way you don't draw things behind walls. And there's other things...

I mentioned AI briefly before. When you pit AI vs. AI. You really get a sense that what you've made has taken on a life of it's own. I treated AI in levels or stages. Picture you have a character on screen. At the lowest level is things like walking/kicking/punching. Simple actions. Above that you have things like: turn to face player and walk to player and when close enough kick. Then above that you have something cool like: use corridor walking AI and when player is sighted change to attack AI. So you can break AI down to smaller solvable problems using a layered approach. Then you can plug player controls into the lowest level of the AI so the player functions like the other characters in the game world.



Now I have pretty much a full game, I can turn it on and just play for hours. Right now I'm transitioning to Enhanced Animations Plugin. It's taking a little longer then I expected. Splitting the upper and lower body for things like running and shooting is tricky. This is because I also aim the torso/arms and weapon up and down to the characters target. After that I want to convert the lighting system from DBP Default to Evolved Normal Maps, but I have to figure out why awful texture seams are appearing on the character's bodies. I suspect I'll be posting about that some time. Something about the Normals not being calculated properly. Then I'll revise the controls so that buttons can be remapped. This will then put me in a position to release a WIP. Specifically I want something playable at day one. Issues like screen resolution and controls need to be bullet proof.

So it's essentially a matter of figuring out what you want to do, then figuring out how to do it. I should also point out that prior programming experience helps a lot since you'll be better at making code efficient, and planning ahead. I have a College Diploma in Electronics Engineering and a Computer Science Degree. I wouldn't be surprised if someone with Doctorate shows up. But these things are helpful and not necessary.

And most importantly, have fun

Oh yeah, and I like to post pictures sometimes because it's great showing people what you are doing, gives people a better idea what you are talking about, and breaks up walls of text nicely.

I like this approach. Kind of like I did years ago but when the going got tough I quit going LOL. I have milkshape, paid version but can't really get into it. I have been using lightwave for years. My mom and dad had it for use in a video business they had and I started playing around with it and was hooked. I am not great at modeling and can not make characters but then I have never really tried characters. I can make buildings, apc's tanks, stuff like that. I am sure I can do swords, war hammers halberd etc... Characters is something I will have to try.



I am interested in this. If you make characters in MS, why do you need to code an editor for this. I know people make world editors and editors for different things but I don't really know why.

I want to do an rpg because that is what I am into I want to loosely remake an old but great 80's game. I was kicking around the idea of a text game which might be a good learning experience for just making maps and learning to write routines, functions types etc... but I am totally interested in 3D and can probably learn all this by doing 3D stuff like you said a matrix, 1 character, 1 building then expand from that is a good way IMHO. This is the way I was going to approach things with FPSC.

I am 52 years old, own a truck and haul steel for a living. I only have a high school education. I think I am one of the smarter high school grads out there even though you would have never known it by my grades at the time. LOL Everything I have learned or wanted to learn after high school is self taught, including some electronics, programming, graphics, marketing on the web, building websites, math etc...

I know a little about a lot but not a lot about anything.

I do look at this as a hobby but if I can get a good game done I would like to build a website and market it and other games and software I make from there. Like I said I studied that for a couple of years.

Thanks Dragonslayer

I need a high degree of customization. When you hard code textures, objects, and other details, you are very limited in what appears in the game. A lot of times this is perfectly OK. In my case in the game world there's a ton of people walking around, and even the player can put on different items, swap weapons, etc.

So I break things down like:
Game World > Level > Character > Item/Script

So when you see a character on screen in a simplified view it has:

an animation state
a physics state

a body object path
a body texture path
a head object path
a head texture path
a hair object path
a hair texture path

up to 15 additional glued clothing items
up to 2 equipped weapons

a 10 slot inventory list
an optional face texture overlay

a name
a race or type
a default AI
a faction
an alignment
a conversation script
a death script
an activation script

So rather than having to add and juggle thousands of lines of code the game simply loads the characters file. All the details of the character are stored in an array, stored in the file. In the level editor there's a list of characters for the level, stored in the level file. That list just points to the character files. The character file references item files. The game loads the level, gets the list of characters, and loads each file in the list as a separate character. The level editor also stores where those characters are positioned and some other details, so the game can create the game world. There's also a degree of optimization i'm glossing over here too.

I should also mention that when the character's file mentions items the character has, like equipped weapons or clothing, these items themselves have their own item files to dictate what type of item it is, their object path name, their texture path name and etc.

When the character's file references a script, its a path name to the scripts separate file. The scripting language is completely custom made specifically for the game. A separate editor handles script files so I don't worry about syntax.

This sort of approach can get bogged down with a lot of file i/o so it's helpful to optimize by copying or linking characters/objects/textures/items if they are already loaded.

So you can see if I was hard coding this it would royally suck. A lot of times this sort of convoluted hierarchy is not needed. However it is if you want to make something like an MMORPG, a sandbox game like Saints Row, or even LittleBigPlanet.