Just starting to create a game, looking for some advice

Hi all, I've got a few general questions about making a game and if someone more experienced could answer a few questions for me that'd be really helpful!

So after a long period of telling myself I'm going to make a game someday I've decided to finally try it out. I have some programming experience already (in python, mostly concerning doing maths with a data set, curve fitting etc), and I've just finished an excellent C# basics tutorial to prime myself for unity (this one, if anyone is interested: youtube.com/ watch?v=GhQdlIFylQ8. I'm just now learning the basics of object oriented programming

My current plan is basically to just start and teach myself everything I need to know as I go along. I'm aware that using this method with programming can often lead to you building your program on bad foundations, so to speak, which can cause a lot of problems down the line, and I have a few questions regarding this:

1. I want to make a game that plays mostly in 2D but takes place in a 3D environment, so while the player sprite moves in 2D 99% of the time, certain moves and events within the game can cause him to change to a different 2D plane, one that is not necessarily parallel to the one he started in. I want to by able to dynamically change between playing within the xy axis, ie top down Binding of Isaac style, to the xz axis, Cuphead style. I also want the player to be able to perform interactions that move outside of his plane while staying within the same plane himself, for example:

if player A is faced with thin enemy B and fat enemy C, with C being behind B, I want the player to be able to shoot around B to hit C if he clicks on C, with the game intelligently recognizing that since C has more width than B, the player can shoot C through B by aiming slightly off to the side (in the z direction if the game is normally played in the xy axis). I figure all of this can be accomplished if I make my 2D sprites having some lengths in all 3 dimensions that are persistent when changing between the xy axis and the xz axis, even if they're only being represented by a 2D sprite (obviously the sprites would have to change when changing between axes). In case it's important, I want this to occur in real time rather than for example as a turn based thing.

Since unity's 2D mode still allows for 3D environments, I'm thinking that I can probably accomplish this using unity 2D and I suspect since unity 2D is simpler, this might make life easier for myself. but since I wont be implementing these features early on so I want to check with you guys first weather this is appropriate or weather I should just use unity 3D, cause I can also imaging trying to include 3D features in unity 2D might end up making life more difficult?

2. Inspired by Dual Universe, I want the player to be able to write and run their own custom written C# code within the game, to do things like program simple AI companions. Again, not something I would like to try and implement early on and I have no idea why this might cause problems when I do, but since it's a very unusual feature I thought I should mention this too in case there are things I should bear in mind if I'm planning to do this later.

3. Is it wise to put off these (or other) more complicated features first while I learn? Or should I just dive right in to the hard stuff and try to get these features working first even if it takes ages, to avoid creating problems later? Or finally, would it be better to get more proficient with C# and unity by making smaller, progressively more advanced games before I start on the one I actually care about? Obviously I'd prefer to go with the first option, but I wont choose it if it's a bad decision

Sorry about the wall of text, and if anyone has any other advice you wish you'd had when you first started, I'd love to hear it!

Thanks,
Jack

 

Learn to code 1st.

The best ting you can do is start small. Code Tic Tac Toe. Then code 4 in a row. Then mix the 2 together!

There is a LOT to learn, and if you just jump in, it will lead down the path of sadness.

If you learn to code properly, when it comes time to code the game, everything just falls into place.

"Everybody" wants to jump in with both feet and code the next GTA (I am guilty of that too!). But 2 years later, I FINALLY have a strong enough foundation I can actually code a game I want. I have created 4 failed projects where I coded myself into a corner and it was just a mess!

 

Thanks for replying! I can already code far more complicated programs than the games you've described. For an idea of where I am now, well, if you asked to write a program to simulate 100 bouncy balls dropped and colliding with each other and the floor/walls in a room, that is something I could do but it would take me a good amount of thought and consideration. If you asked me to show that visually using graphics however, I wouldn't know where to start.
(I'm coming from a science background so I've written a few programs ~ 500 lines long that are very maths heavy, but if it isn't prerequisite for a physics simulation or data analysis, eg graphical stuff beyond basic xy graphs, I probably haven't touched it).
So my follow up is, roughly how well do I need to know how to code before getting started?

 

All I am saying is, you have to crawl before you walk and you have to walk before you run. So... With that said. Go ahead and make 100 bouncy balls. Have the user choose whether to spawn them from one location or random. Maybe randomize their sizes using perlin noise, etc... Learn how the system works before you code your game.

A rule to go by is, 1 class, 1 function. If you code a class and it does more than one thing, it needs to be split. Generally speaking a class should be around 200 lines(but, I do break that rule from time to time). My animation controllers tend to get quite long. Luckily I code them so that ANYTHING that needs animation can use the same code.

I am not a coding master by any means, but I have seen people code their entire game in one class, and it is horrible! Can you imagine scrolling 14 pages to find that one method you were looking for?? Your player controller should ONLY move the player. It should get input from your input controller. Your health bar, should be in it's own class accessing your health class thru an event.

The list goes on. LOL a LOT to take in.

 

I'm new to object oriented programming so that's useful information to bear in mind regarding classes, I guess I'll try to make a side scrolling game with some basic physics before I get started on anything more complicated.

When you say the list goes on, is there any chance you could give me a longer list of things I should cover before I get started on the game I want to make? That way I can work my way through it

Thanks!

 

Well, I've been around since Apple Basic. I've coded in Fortan, Pascal, ASM, PowerBasic, MS Basic, JavaScrpt, PHP, and now with Unity C#. I have basically been watching videos on Youtube and found a style of programming that fits me. I Prefer the one job/One Class mentality. I LOVE being able to create an event system, and by simply listening to that event with another class, I add a whole new process to the game. The whole time, if this one process is garbage, I can just take it out without effecting what I have already written.

I fell into the trap of just adding code on top of other code, and changing 1 thing in the new code, topples the whole game.

Learn event driven programming and delegates!

My latest trick involves using 2 cameras. 1 for the scene and one JUST for UI elements. My inventory is on it's own UI layer, my "Health" (in quotes because it shows hunger, fatigue, etc...) is on it's own UI layer. If I hit the key/press the button that activates that section, it's toggled as viewable by the UI camera.

I don't disable it as it has scripts that watch for events triggered and adjusts it's info accordingly where it's visible or not.

If I need my character to do something, I "ask" my input controller if I am pressing the right keys/buttons to do it.

This allows me to create a control customization screen that ONLY changes what keys/buttons are selected to perform that action. The code is NOT buried in 25 different classes. It's in 1 class, in one place only.

I have done this with common functions as well. I have a custom search method to find object by string name. And an overload that will only search an object's hierarchy if it is passed an object.

I would just suggest spending some time watching youtube videos. Take note of how they code, and what they are coding. In the meantime, draw up what you want your screen to look like, how you want to interact with your world, etc... Try coding ONLY the camera controller. Do NOT include a character controller. You can manually move your "player" in the scene view. Once you have it working, then code ONLY your inputmanager. THEN you can code your controller. 1 module at a time.

Learn scriptable Objects!

Let's say I have a pistol I have prototyped and everything works exactly as I want it to work.

I simply copy that object, copy it's scriptable object(s), change the name, change the mesh, change the scriptable object data, and I now have added a new weapon. I can change it's fire rate, range, and damage by editing the scriptable object data.

 

Yeah, I love using youtube videos to learn too. Also "I fell into the trap of just adding code on top of other code, and changing 1 thing in the new code, topples the whole game" is really good advice. I had a similar problem with one of my programs at university, because I was using functions that tried to do too much, instead of breaking them up into smaller functions. An important lesson to learn!

Anyway, you've convinced me it's a bad idea to get started on my main game without starting simpler first, and given me a lot to work with, so thanks for all the help!!

 

In the end, you will be much happier with what you have. Then, while you are relaxing playing your game, you will be inspired to another more difficult game. The great thing is, you've coded modular, so you already have a LOT of the code you need!

 

This generally considered the best way to do it. Finishing small projects while progressively increasing your scope, will give you the experience that you need to organize a large project. People on the forum can answer specific questions like "How do I handle key presses?" or "How do I make a projectile", but the most difficult part is putting all of these aspects together into a single cohesive project, and that's much harder to do over a web forum.

In any case, I would save the whole letting-the-player-write-their-own-code feature for a later game because that will probably be a lot more difficult than anything else that you mentioned.

 

All the people saying to start small are the morons who started real big, got burnt, and now are trying to do a favor. We are all dummies. Don't join the club.

 

@BIGTIMEMASTER please mind your language.

 

i am sure the subtext is understood. it's not an insult.

 

I mean one specific word, not the context itself, since you are addressing part of the cummunity. We should avoid using such colorful words, where are not needed

 

IMO, it's a bigger show of respect to a person to expect them to have the basic resiliency and confidence of an adult, rather than treating people like infants ready to cry at anything.

I am sure the mods will swoop in with their talons and teach me a lesson if I am breaking some rules.

 

i literaly signed up to say you made me laugh like a witch 10/10 more joke pls

 

Basically you want us to tell you how to create your own game.
It is you who needs to figure out how to write his own game.
From your post I understand your knowledge in game development or the Unity engine is practically non existent.

Most of us have spent many years of development, creating S***ty games, then better and even better games with time, as we make a S***load of mistakes and just gather new knowledge and get better in game design/programming.

You have to go through the same process and there is no way around it.

Otherwise you can hire some experienced dev for S***load of money to develop your game, this is always a possibility.
The other way that we have all walked is to start with very simple things, be patient, create stuff, iterate, improve on it and with time become better. Then most of the answers of your questions will come along the way.

 

When you want to implement the first point you should first do something where the player can actually walk and shoot and after that you can try to make extra things like thin and fat enemies.
Perhaps you can do it in 2d and simulate the shot on the z axis. So when you cast a ray which collect alls objects and the thin and fat one is hit you can write a logic that the thin ones dont block the shot when you targeting fatty.
For implementing the second point (sound like modding) I would actually first try to finish the first one. It also helps you a lot more to do a finishedgame.

If your main goal is to make a game stick to point one and perhaps forget the second one for the moment.
If your main goal is simply to learn new things you can try both things in an experimental way. Both features will make you learn a lot i think.

 

Interesting read. Specifically from BIGTIMEMASTER.
I am that guy who spent countless hours playing games since the 1980s developing an enormous amount of criticism of what games do well, do right and should be better/different. Finally deciding to spend my new found spare time doing that which I dreamed about all those years. I literally came here for that reason, lurking at bit at first. Everyone is saying start small. EVERYONE. Not a single article, video or forum post I have read has said anything otherwise. My logical side is telling me that it makes perfect sense.I have no delusions that I am going to be able to development my dream with zero prior development experience. Still, I am unwilling to let go of that dream.

Clearly the best advice is to learn the tools you are working with. Work within your abilities and do not try to overcome major roadblocks on your own. My first project is to do just that. A completely stripped down version of my dream. Basically a stick man/block able to navigate an environment of my own creation, albeit a extremely simplified one.

In short, I understand why everyone says start small/simple. Coming out of the gate it would an ominous task to develop your triple AAA concept with new previous experience and natural short comings in efficiency. Though BIGTIMEMASTER makes a valid point. The dream brought you to this point. Use these small/simple princibles to take steps to your ultimate goal.