[Question] What abilities should I adquire for general game modding?

[CrazySquid]

Hi, first, sorry if something like this was asked in the past, I saw some posts but they did seem a bit different compared to what I was searching.

Well, similar to what the title says, I would like to know what abilities should I learn to do some general modding.

Right now, I ACTUALLY want to mod a specific console game, that is, Dragon Ball Z Budokai Tenkaichi 3 for Wii.
Problem is, most mods come from the PS2 version, and so far, they seem to have different files, meaning that just swapping mods between the PS2 and Wii versions is not going to work.
Same applies to 3D models, DKZ list all files like .unk (Unknow, I think), so converting them to .obj isn't straigtforward, except for the PS2 where such tools for BT3 do exist, but for the Wii version that is not the case. I tried the PS2 tools anyway, but yeah, they don't work with Wii files.
So basically, I would like to know how to deal with stuff like that for example, how to know how to convert those models in those weird extensions into something more "standard" like a .obj.

Other things would be how they change animations for techniques, etc. I saw they use some hex editing for some stuff...

If you ask, there is a Tenkaichi 3 Wii modding community, but it's a bit toxic and nobody is willing to help each other, unless you already know your sh*t, or you are asking very basic stuff like changing music or life bars, so they give you some tips, but they will not release any converting tool to make more sophisticated mods because "this took me a lot of effort to figure out, so I'm not sharing, why would I would do that? Figure it out yourself '.
Heck, they even do the same stupid joke every year (april fools, and for the Day of the Holy Innocents at the end of the year) saying "Here is the video tutorial showing how to port PS2 models to Wii", just to make you download a f*cking fake tool (Yes, they take the time to troll you like that, they code a fake tool...) saying that it will convert the .unk PS2 file into a Wii .unk file... the tool doesn't actually do anything, but the guy wasted time doing that prank. (Sorry about the rant, but it really makes you mad when you try to learn something to help the community grow, and not only they don't help, but even take it as a joke and mess around with it).

So far, the things I think I should learn are:
-C/C++ coding
-Hex editing
-Blender (For modeling and animation)

If someone more experiencied with modding in general could give me advice in what else should I learn, I would be grateful! Note that I'm not actually asking for help in modding DBZBT3 Wii, but rather, what should I know, or what abilities should I adquire to be capable of FIGURE IT OUT on my own and work on it myself.

Thanks! Sorry if the redaction isn't clear, just tell me if it is confusing and I will clear it up!

 

[FAST6191]

Never encountered this before in game modding, some resonances with a few cheat making circles but game modding is new. Most ROM hackers I have ever met don't necessarily want to do your homework for you as it were but will share all info they find and usually be happy someone else takes an interest, and outline paths for you to do what you want to do or tell you why it is unlikely to happen. If it was going to be anything though then I guess I would put money on the Dragon Ball modding set... drama factory that side of things is at times. Though if you really care about the games (I don't know why, most are not great games with little scope for modders to make them that much better) then if that is the state of play then you could probably blow said elitism out of the water fairly easily.

Game modding is broken down into various areas. PC stuff usually sites way aside from console stuff (where ROM hacking is probably the better term) owing to the former being dominated by dev released tools.
ROM hacking then being broken down between premade tools and those that go more manual, the manual crowd then usually having a distinction between those that can edit files and those that can deal with assembly code (an annoying and old school method of coding but owing to... physics is the only way to edit the vast vast vast majority of console game code in a meaningful way to run within the console itself, Lua for some emulators can do some interesting things that might otherwise be hard).

C/C++ you can learn, how immediately useful it will be is questionable. Indeed it might give you some insights into assembly but for the most part it is useful only for making tools, and for tools any programming language will pretty much do. C and C++ is there more for when you need fast code (so emulators, high end rendering, serious data conversion and analysis and so forth).
Hex editing is not a thing, or at least you can learn to use a hex editor all you want but it is akin to being able to use a word processor and wanting to write a novel in that it is not going to hurt such endeavours but also not do much.
Blender is a popular open source 3d modelling tool, one a fair few people have made plugins (which may be where C family languages come back in a bit more than some others as it leans a bit towards that but ultimately nothing too drastic) for various game related formats for. I don't necessarily suggest converting to a common format unless your goal is a PC port of things (want to make a mugen model or new game in whatever engine), though I can see the appeal compared to 2d graphics and audio where most would way converting to common formats is a questionable act and only do it if you have to.


I have a guide https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ , it is more focused on GBA and DS stuff but the principles apply to everything.

If models are going to be your focus then you need to learn about 3d hardware of the consoles in question as everything will play to it (wasting resources converting formats in game gains you nothing and probably causes slowdowns, restricts how much you can have on screen and more besides). I don't know what level to start you out at here -- do I do bones/skeletal vs vertex (the big split in 3d modelling, possibly not a thing you get to deal with for this particular project but maybe for some others if you move to other systems), ponder things like gimbal lock, teach you about floating point numbers (fractional numbers are all but essential in 3d modelling where they are not in most other/older things).
I suppose I will note that 3d is comprised of 3 main areas, maybe four in the modern world.
1) Models. These are the representation of the physical item, if you were going to 3d print/CNC something then this is that.
2) Textures. These are the things that give it colours.
3) Animations. These are what makes the models move in the game.
Modern world 4) would include shaders. If you want to think of them as filters you would not be so far wrong. The concept goes very far back though; if throwing out old school fun terms to look up of little particular relevance to the matter at hand then I would say go look at Gouraud shading and phong shading.

There are ways to blur the lines -- texture animations exist wherein textures themselves are smooshed around or replaced, modern textures can include depth data (though I doubt the PS2 nor wii had them), models can have basic colours and vertex colours (the DS for instance having this and quite a few things using them), and someone shoving a slightly tinted block in front of the camera (3d or 2d hardware maybe doing the deed) can effect some kind of shader setup.

Porting a model then sees you have to learn the format of the source you are coming from, the format you are going to and having to work it such that the destination game also knows what to do with it -- for instance you have to start somewhere so if the wii game says move vertex 1 up by 10,15,12 over the next 10 frames and vertex 1 on the wii game is the tip of a hand then your dutifully converted model from the PS2 had better start numbering there rather than say having 1 as the tip of the head lest you get oddities. PS2 might also be lower polygon count than the Wii (older hardware after all) so you then get to figure out what to do there and we then get into the "more art than science" side of things (at least until AI takes over) as pressing subsurf (takes a few points and makes a curve, not a bad way to add some detail/smoothness where there was none/blockiness before) is not going to always do what you want/what looks good. I might instead suggest learning to edit a model within the same game (two games on the same console can also have this set of problems, though usually lessened) and then embarking upon porting efforts.

 

[CrazySquid]

Never encountered this before in game modding, some resonances with a few cheat making circles but game modding is new. Most ROM hackers I have ever met don't necessarily want to do your homework for you as it were but will share all info they find and usually be happy someone else takes an interest, and outline paths for you to do what you want to do or tell you why it is unlikely to happen. If it was going to be anything though then I guess I would put money on the Dragon Ball modding set... drama factory that side of things is at times. Though if you really care about the games (I don't know why, most are not great games with little scope for modders to make them that much better) then if that is the state of play then you could probably blow said elitism out of the water fairly easily.

Yeah, I was a bit dissapointed because there are a lot of tools on the PS2's Tenkaichi 3 community which saves you a lot of the hassle to create mods there, such as custom characters... heck, there are even some guys that shows how they port a .obj model from Blender to the .unk format of the game (using tools) and then they have the model swap working in-game (I know they have to modify the skeleton or things like that to match the original model structure, also the new model size can't be bigger than the older one, otherwise it doesn't work). Those methods do exist for Wii as well, but they are not public... so that's why I'm looking forward to understand more about game modding and develop those methods they did, but on my own.

Game modding is broken down into various areas. PC stuff usually sites way aside from console stuff (where ROM hacking is probably the better term) owing to the former being dominated by dev released tools.
ROM hacking then being broken down between premade tools and those that go more manual, the manual crowd then usually having a distinction between those that can edit files and those that can deal with assembly code (an annoying and old school method of coding but owing to... physics is the only way to edit the vast vast vast majority of console game code in a meaningful way to run within the console itself, Lua for some emulators can do some interesting things that might otherwise be hard).

The closest I was with modding was with Valve's Source engine, GMOD, SFM... but... eh, I didn't do something too impresive, and yes, it's like that, PC has a lot of released dev tools, but that doesn't apply to what I'm trying to achieve unfortunately :/ .

Let's just say that I want to achieve modding, but there are no tools available for that. Some console games uses a custom engine that doesn't have conventional model formats (in fact, a lot of files in the game are .unk files and have weird names like "ƒAƒ(2735).unk"... which makes me wonder, how the hell do people figure out that that is a model file and not something else?)
There are some other files like ".adx" that when you Google them, you can understand that those are audio files... but I don't know how they do figure out about other "generic" files. I remember in the past swapping those audio files with others, and I kind of managed to get my desired result.

Even so, if you figure out that a weird file like the "ƒAƒ(2735)" is a model from a character... how do you even get to work with it? Since it's custom stuff and it won't load in normal programs such Blender (unless you can convert them).

Those are some things that comes to my mind and I don't have a clue how they deal with that stuff. Like figuring out what each file does, etc...

C/C++ you can learn, how immediately useful it will be is questionable. Indeed it might give you some insights into assembly but for the most part it is useful only for making tools, and for tools any programming language will pretty much do. C and C++ is there more for when you need fast code (so emulators, high end rendering, serious data conversion and analysis and so forth).
Hex editing is not a thing, or at least you can learn to use a hex editor all you want but it is akin to being able to use a word processor and wanting to write a novel in that it is not going to hurt such endeavours but also not do much.
Blender is a popular open source 3d modelling tool, one a fair few people have made plugins (which may be where C family languages come back in a bit more than some others as it leans a bit towards that but ultimately nothing too drastic) for various game related formats for. I don't necessarily suggest converting to a common format unless your goal is a PC port of things (want to make a mugen model or new game in whatever engine), though I can see the appeal compared to 2d graphics and audio where most would way converting to common formats is a questionable act and only do it if you have to.

I see, I'm still interested in C/C++ since I would like to contribute to homebrew in the future, so I think it will come handy! You are suggesting that I should need to learn assembly to do game modding? So... for the Wii it would be PPC assembly, and the for the PS2 would be MIPS assembly?

Regarding hex editing, I mentioned that because the few tips I saw they released for the Wii version of the game involves Hex editing, with this, you can change stuff like life bars, Ki bars, or edit techniques slots IIRC.
So, that's why I thought about hex editing, but now I'm realizing that I think that I worded that wrong.
Not all hex is equal, I mean, when you edit hexadecimal code, you are dealing with machine code, right? If that's the case, then it means that not all hex is equal... so... Hex editing will only be useful if I understand the game's machine code? (Which if this is correct, it leaves me with another question... how the hell you do figure out what part of the machine code does what? Like... how do you know the exact part that controls the life bars? Just looking at it seems like a work that could take months of trial and error until you find it... or maybe not even that, but you may actually never find it by trial and error)

About the common format, AFAIK when I saw some guys (the actual not toxic ones from the PS2 community), they work methodology was to first convert the model into a common one, edit it in Blender, then back to the .unk format, then swap the contents. Of course, I oversimplified things, but that's more or less what I saw.
But that seems to work so far.

I have a guide https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ , it is more focused on GBA and DS stuff but the principles apply to everything.

That write up it's pretty good! I see that is focused in the GBA/DS, but still found it pretty informative.
In fact, the method to know what the hell the hex code does by corrupting and testing looks interesting, seems like trial and error, but is different that was I was thinking before.
Also, saw that emulators help a lot with console modding, just with memory viewers and the like... I think Dolphin will come handy for more than just testing the game with no need to boot it into the console.

If models are going to be your focus then you need to learn about 3d hardware of the consoles in question as everything will play to it (wasting resources converting formats in game gains you nothing and probably causes slowdowns, restricts how much you can have on screen and more besides).

Hm... Yeah, but isn't that too low level stuff? Usually the mods I have seen are just model swaps with new animations, but they need to be the same size of the original model, otherwise it doesn't work. The process I have seen with the PS2 was:
Grab the .unk model ---> Convert it to .obj ---> Do your magic on Blender ---> Back to the game

I don't know what level to start you out at here -- do I do bones/skeletal vs vertex (the big split in 3d modelling, possibly not a thing you get to deal with for this particular project but maybe for some others if you move to other systems), ponder things like gimbal lock, teach you about floating point numbers (fractional numbers are all but essential in 3d modelling where they are not in most other/older things).
I suppose I will note that 3d is comprised of 3 main areas, maybe four in the modern world.
1) Models. These are the representation of the physical item, if you were going to 3d print/CNC something then this is that.
2) Textures. These are the things that give it colours.
3) Animations. These are what makes the models move in the game.
Modern world 4) would include shaders. If you want to think of them as filters you would not be so far wrong. The concept goes very far back though; if throwing out old school fun terms to look up of little particular relevance to the matter at hand then I would say go look at Gouraud shading and phong shading.

Hm... never heard of vertex, I always thought that bones/skeletal was the only way,
But yes, about floating point numbers and the like I know a bit of it, I was studying an system enginerring career and I know about floating point (at least, if we are talking about IEEE 754, I know some system like the 3DS are not compliant, but do support floating-point).
Had to stop studying because it was a very intensive career that was sucking up my life and I wasn't capable of handle it, but.... it seems I was learning more useful stuff that what I was aware of, I did see a bit of assembly just to understand how the Intel's 8086 processor worked (Using emu8086, SimuProc, and other stuff).
Guess I should try to get more order in life and see If I can give that career another shot, seems what I was learning there to be pretty useful for these kind of things.

Porting a model then sees you have to learn the format of the source you are coming from, the format you are going to and having to work it such that the destination game also knows what to do with it -- for instance you have to start somewhere so if the wii game says move vertex 1 up by 10,15,12 over the next 10 frames and vertex 1 on the wii game is the tip of a hand then your dutifully converted model from the PS2 had better start numbering there rather than say having 1 as the tip of the head lest you get oddities. PS2 might also be lower polygon count than the Wii (older hardware after all) so you then get to figure out what to do there and we then get into the "more art than science" side of things (at least until AI takes over) as pressing subsurf (takes a few points and makes a curve, not a bad way to add some detail/smoothness where there was none/blockiness before) is not going to always do what you want/what looks good. I might instead suggest learning to edit a model within the same game (two games on the same console can also have this set of problems, though usually lessened) and then embarking upon porting efforts.

I see... Hm... Do you know of some course that focuses on reverse enginnering files? I mean, I have read your PDF and seems that one way to know what kind of file is each is to read the header of the file (File signature is called?) so you can know at least what kind you are dealing with, right? I tried that with the .unk file, but it doesn't seem to show me anything to know what kind of data it holds.

Thanks for your reply!

 

[FAST6191]

C and C++ for homebrew would make it more useful for you, C++ tends to be for more powerful systems owing to the overhead.

They are particular sub types of PPC and MIPS (come to the GBA with the ARM knowledge from a modern mobile phone and you are going to know a fair bit but also have to forget a few things and deal with some limitations), and that is usually only the start as the consoles themselves will have all the internal hardware on top of that. I don't know what we are pointing at for the Wii and PS2 these days but emulator source code and documentation, homebrew documentation (Wiibrew has a few things here) and such like are usually where it starts.

Figuring out formats is the whole trick really. Internal analysis, analysis with respect to the hardware (no sense in converting on the fly so if the internal 2d hardware takes certain commands/matricies/number formats look to see if anything looks like a list of them), analysis with respect to what you expect (there are limited ways of doing things in computing most of the time, and things that have to get done to achieve a goal, usually enough to give you a start to know what to look for), seeing if someone else has gone before you ( http://wiki.xentax.com/index.php/Game_File_Format_Central https://wiki.multimedia.cx/index.php?title=Category:Game_Formats https://doc.kodewerx.org/ ), comparative analysis (chances are your 3d character model is sitting in a directory with a bunch of others, if you know what each might do in the game the differences you can observe in play will be reflected, in the case of dragon ball a lot of characters are quite visually distinct as well with all sorts of things jutting off and dangly bits. Likewise if the devs were kind enough to leave a simplified model in there somewhere either as a joke, developer leftover, some piece of background scenery... then reverse engineering a cube, sphere or one the other 3d modeller basics is often far nicer than leaping right in at the deep end) and even a whole lot of what does this button do (expensive if you have to burn a CD every time, fortunately emulators, USB mods and flash carts exist such that. If this was security discussions then that would be unfettered access to an oracle -- you might not know what the black box does. Much like file swapping still likely means you have a valid file then I would usually suggest things from the same file or other file to hope you are sticking within expected ranges as most games have no kind of file input sanity checking - not like users create their own files in a read only memory scenario to warrant the resources when it could be putting more polygons on screen).

Not all hex is machine code. Indeed relative file size on disc that is very far from the case, and indeed even within the actual binaries some will probably fall below half by the time whatever non code stuff is contemplated (devs often enough ram in data tables, text and such in the code itself, bad form but the hacker's lot is to deal with what is there rather than what would be under ideal coding standards*)

*your mentioning a supposed limitation of same size model is indeed such a thing, though I would say it is less of a hard one than some might think. It gets a lot more tedious and you might have to change a bunch of animations as well, probably not collision data/hitboxes for 3d models but could also be that if the dangly bits don't count and there might even be a memory limitation at some level but most of those can be worked around.

Life bar editing.
Start with a cheat, though there are other options. https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial if you are not familiar with cheat making.
From there welcome to the world of tracing. Higher end emulators might have debuggers that have breakpoints. Break on read aka BPR (stop when this area of memory is read), break on write aka BPW (stop when this area is written to), break on execute aka BPE or BOE in some setups (break when this area is executed as code). Run to line is a special case of BPE and there is also break on access where one or more of the above are combined into one.
The other options also kick in here -- you want some change to key in on so graphics, audio channels, reading of part of the ROM, reading of buttons... all potential options for things you might want to edit.
https://www.romhacking.net/documents/361/ is for a command line GBA debugger but the principles apply, I have some others in my guide as well. I don't know what we are suggesting for debuggers for Wii and PS2 these days. Dolphin used to have one but you might have to find a special old version, no idea what PCSX2 has going on these days offhand. Not all emulators will have an internal setup so you might have to attach something like https://wrongbaud.github.io/posts/ghidra-debugger/ , IDA or even a conventional debugger to it with GDB or something.
As far as binaries themselves then for consoles with a file system then the binaries and formats thereof are usually fairly well known/documented (most non Microsoft consoles using some variation on the theme of ELF).

Re low level hardware. In science one tends to want to understand the level above that which they are playing with, works pretty well here too. Equally it will help with the blender aspects, and possibly move the needle as well (if you look across at mario kart https://wiki.tockdom.com/wiki/Main_Page and see all the fun people are having there with porting every kart racer track they can get their hands on to mario kart then that could be you for this game, and I know they understand all that to do what they do, they also have to deal with collisions too though in this case it is the track layout rather than what is hit).

Courses that deal with things... a lot of it is pull yourself up by your bootstraps and pull little bits from everywhere. Many will write things up (I have linked several places where you might find lots over the course of this). Usually it is a combo of such links, hacker conferences (c3, defcon, black hat for the big three, all nice video archives these days, very little explicitly ROM hacking in those but duality of knowledge applies always in this), writeups people make for their hacks on tricky things they encountered. I wrote mine as an attempt to make things a bit more cohesive but probably ended up more https://xkcd.com/927/ which is fine. Though above all I should note computers have ctrl and Z, and ctrl and C and ctrl and V for a reason, works very nicely in this.

The header thing, magic stamps being the term many will use but signature works as long as you don't get confused with the cryptography concept that might well be in play -- long sorted but wii trucha bug and fakesigning would be a thing in play there, and start editing save files and it will come back in a hurry. It is a common enough convention in file system based devices (the GBA is not one, by any large anything older than a DS and comes on a cartridge or tape is all stuffed in the binary/incbin, anything that came on floppy disc or optical media is file system based, though there are exceptions) and within a system as well. Can help too when file names and extensions are changed from "standard" ones.

 

[CrazySquid]

Life bar editing.
Start with a cheat, though there are other options. https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial if you are not familiar with cheat making.
From there welcome to the world of tracing. Higher end emulators might have debuggers that have breakpoints. Break on read aka BPR (stop when this area of memory is read), break on write aka BPW (stop when this area is written to), break on execute aka BPE or BOE in some setups (break when this area is executed as code). Run to line is a special case of BPE and there is also break on access where one or more of the above are combined into one.
The other options also kick in here -- you want some change to key in on so graphics, audio channels, reading of part of the ROM, reading of buttons... all potential options for things you might want to edit.
https://www.romhacking.net/documents/361/ is for a command line GBA debugger but the principles apply, I have some others in my guide as well. I don't know what we are suggesting for debuggers for Wii and PS2 these days. Dolphin used to have one but you might have to find a special old version, no idea what PCSX2 has going on these days offhand. Not all emulators will have an internal setup so you might have to attach something like https://wrongbaud.github.io/posts/ghidra-debugger/ , IDA or even a conventional debugger to it with GDB or something.
As far as binaries themselves then for consoles with a file system then the binaries and formats thereof are usually fairly well known/documented (most non Microsoft consoles using some variation on the theme of ELF).

I checked that page for creating a cheat in the Mario game and I liked, seems like fun stuff, even if basic (I don't have much knowledge about this, but looked at it and understood it, I think I will enjoy doing that).
I even saw that it has some exercises to test your skills, that's pretty nice! I will definitely give that a shot.

Regarding the debugger, I found this video on Youtube, I think this is what I'm looking for, right? (Wii Modding)

Re low level hardware. In science one tends to want to understand the level above that which they are playing with, works pretty well here too. Equally it will help with the blender aspects, and possibly move the needle as well (if you look across at mario kart https://wiki.tockdom.com/wiki/Main_Page and see all the fun people are having there with porting every kart racer track they can get their hands on to mario kart then that could be you for this game, and I know they understand all that to do what they do, they also have to deal with collisions too though in this case it is the track layout rather than what is hit).

I checked that wiki too, and the game I was interested in (talking about Mario Kart) is Mario Kart 8.
I saw that some documentation regarding creating tracks, but it was interesting that people that create tracks there tell what programs they used, so in that case the process is more or less know and the modding community seems way more healthier.
Editing stages and other stuff is something I would like, but I think starting making cheats for GBA games may be a good little start.

Courses that deal with things... a lot of it is pull yourself up by your bootstraps and pull little bits from everywhere. Many will write things up (I have linked several places where you might find lots over the course of this). Usually it is a combo of such links, hacker conferences (c3, defcon, black hat for the big three, all nice video archives these days, very little explicitly ROM hacking in those but duality of knowledge applies always in this), writeups people make for their hacks on tricky things they encountered. I wrote mine as an attempt to make things a bit more cohesive but probably ended up more https://xkcd.com/927/ which is fine. Though above all I should note computers have ctrl and Z, and ctrl and C and ctrl and V for a reason, works very nicely in this.

I see, I will look at those things, I tried looking for some reverse enginerring courses, but most of them relates to malware stuff. Although I did find an interesting video talking about the topic, and seems to be more or less recent.


I will check all of that out, I did use IDA Pro in the past to mess up with the Wii U's RPX file of games, so I could try to force the internal game resolution from 720p to 1080p in some games.
Due to lazyness I ended up leaving it, but I remember that I found a lot of functions thanks to a plugin I have added that was made by BullyWiiPlaza iirc, some was about adjusting height and width using some GX2 functions which I think they may set the actual game resolution... but I was a bit discouraged to continue because I didn't really know what I was doing, and at the same time it wasn't a very smart thing to do because... well, if the game doesn't run at 1080p, there is a reason for it. I just thought that it was not worth the effort and ended up abandoning it (Which I think I regret, since I haven't done anything interested either after that).

Anyway, I will look for the GBA stuff since I believe that's a good place to start by making cheats, and maybe I can continue with more complex stuff after I get more confident with that!

 

[VinsCool]

Honestly, I am not really sure how to narrow it down, so I will share most of what is personal experience here:

- Patience
For fucking around, there is no dumb idea, but it will take a lot of time to even get anything useful out of the experiments.

- Observation
Very useful for finding patterns, identify what does what, where it is and how it could be edited.

- Dedication
Related to the previous qualities, it will take a lot of work to get anything, so if you are passionate in what you are doing, or better, have fun in what you are doing, higher the chances are that you will figure things out, and acquire the experience for future endeavours.

That's probably the main 3 traits I think will be the most important, but there is obviously a lot more to consider, especially if you are someone who start plunging into something from zero, in this case it is very difficult to get started, but it will pay off on the long run.