Overwhelmed! >:[

[Toothless]

Ive definitely been doing my homework: Ive watched a combined ~8hrs of GM intro videos (the ones on GM's site). But Im still completely new.

Ive read and taken notes from a GM essentials book from Amazon.

I feel comfortable with the general programming syntax and the ability to either code or hunt down the methods needed to code.

But despite all of that and having a very clear vision of what I want to do, Im not sure where to start. Im essentially making a game based off of a board game in development.

For those familiar, essentially I need to make something very close to X-Wing. I need to have multiple unit types, the ability to design a squad from those units using a points limiting system, and then combat those units against an AI team on a game board in a turn based system.

Each facet of this seems like something I have a grasp of doing in GM from my preliminary studies. But I dont know WHERE to start, how to order my operations so to speak.

I know I need a 1)splash screen, 2) a menu, 3) a squad building screen, 4) a combat screen using the units selected. But I dont know where to start, I feel silly asking but what kind of work flow can any of you suggest? How would you go about this?

 

[FrostyCat]

Whenever I see aggressive tutorial-mongering on the scale you demonstrated, the usual result is superficial copying instead of actual learning.

If you can't make a splash screen, that means you forgot all about alarms, movement and changing rooms.

If you can't make a menu, that means you forgot all about mouse input, either in the form of Mouse Press events or mouse_check_button_pressed().

If you can't make a squad building screen, that means you forgot all about arrays and global variables.

If you can't make a combat screen, that means you forgot everything that a squad building screen relies on. It's just a variation on a squad building screen, except the input can also contain computer generated data for the other side.

I am absolutely not inclined to believe that all of the 8 hours of videos and instructions on the Amazon book would skip over all these basics. Even the most incompetent GM book I've seen covered at least alarms, movement, rooms, mouse input, arrays and global variables. Everything you need is probably already part of what you've seen, the problem is you being more interested in simply copying off them instead of deriving reusable techniques off them.

Don't put a name on large superficial elements and expect an answer to come out of it. Instead spend some time thinking what they are made of, and answers are more likely to come from the smaller abstract pieces.

 

[Cameron]

As a general rule, don't create menus and splash screen until you need them. You are going to be restarting your game thousands of times as you work on it, do you really want to code those first just so they can slow you down?
Same thing goes with large audio files or audio files in general.
Basically you want your game to compile quickly and be in the game room working as fast as possible in the beginning.
That should narrow down your options of where to start. Other than that, just start building a foundation. If you built a house would you start with the roof?

 

[blandanablandana]

Everything you need is probably already part of what you've seen.

answers are more likely to come from the smaller abstract pieces.

These are two really good lines. Im very new to gamemaker but I've been having to focus on smaller goals instead of longer term ideas until I feel comfortable knowing I can make what I want. I agree with FrostyCat, it just takes practice. You can always save a backup of your project and restart if it's not working. The first few "games" i tried to make I ended up being really sloppy and just experimenting and never finished anything but after I started getting used to being able to save things and understand you don't need to rewrite everything all the time it started getting a lot easier. I find that I tend to find chunks of code that I really like and then put them together once I understand how they work.

 

[Smiechu]

Like above...
You need to start from the foundations... there is no other way. And in every game the foundation is the so called "engine" (I don't mean here the GMS) - the core system of the game which describes and defines the basic gameplay, rules and mechanics. If you are trying to create a turn based strategy game, your core system is the battlefield. You need to define how the data and information regarding what is happening on the battlefield will be stored, executed and displayed. You need to gather all the requirements and create a concept how should this core system work. When you have the full concept, start coding. You probably need some kind of "grid"...

 

[Cpaz]

I guess to sort of reiterate what everyone else has been saying, I've also been guilty of going too big too soon. While these projects never saw the light of day (thankfully) I've also learned plenty for longer term projects through them.
Even still, I should definitely have started smaller do I had a better idea of project management too, not just programming basics.

 

[Rob]

You gotta dive in and get to the point where you DO feel confident and comfortable with making the game you want to make. If you're an absolute beginner, do the "My First Game" tutorials.

Now you know what systems your game needs, prototype or do tutorials on that. Tutorials are helpful but they don't always TEACH what you need to know. Do tutorials so you have an idea and then do your own work.

You just need to invest time into programming so you gain experience.

 

[Yal]

I'd say that you should take a step back and ask yourself some questions about what you've learned, seeing them from the other side. You've been learning things from the bottom up so far, concepts and raw interactions. Now it's time to think top-down instead.

• How can you make things move around?
• How can you store data, and access it later?
  
• How can you control timing?
• How can you take player input?
• How can you present information to the player?

Figure out at least one answer to each of those questions, preferably as many as you can think of (there's always more than one way to do stuff with programming). Once you have the answers, think about how you could achieve what you want with those methods.

 

[Piece0pie]

Hey Toothless,

I would probably start with creating some of the basic board mechanics. I am not super familiar with X-Wing and the mechanics but I assume that it involves playing cards and moving game pieces in some respect so starting there would not be a bad idea. The menu and splash screen are easy things you can implement later on. Personally I save those for when I get stuck on a mechanic and want a break. The same probably applies to the squad screen and combat. Once you get some of the mechanics working (and perhaps hardcode squad assignments to test them out in play) it will be more straight forward to create a section screen.

Best of luck on your endeavors. Don't let the muggles get you down!

Regards,
Pie

 

[Pfap]

I've never played the game you have mentioned, but from your sentence:

For those familiar, essentially I need to make something very close to X-Wing. I need to have multiple unit types, the ability to design a squad from those units using a points limiting system, and then combat those units against an AI team on a game board in a turn based system.

That is probably where you should start, actually getting the work done can be hard. From what you wrote up there though, I already have some really broad ideas on about what could be done, but actually getting things to work is the challenge.

Anyways, here goes...
I would probably start by creating a separate object for each unit type. Lets say you have an X-wing and a tie-fighter you could create 2 objects and give them parameters stuff like max_speed and fire_rate. Then I am not sure what you mean by points limiting system, but you could work that in here to possibly. I'm guessing you mean something like you have 2 defensive heavy fighter and then maybe 4 agile attack squadrons or something like that which is logic you would have to figure out. Stuff you've probably seen in tutorials like, if the player has this fighter selected then don't allow the player to select this.

Otherwise, my only other advice would be that paralysis by analysis seems to be an issue regardless of how much experience an individual accumulates. There are so many different ways to do things and the more you know the more options you have, which doesn't necessarily make things "easier" it may make things more possible, but it always comes down to getting dirty and doing the work.

So, just start working on the part you think will be the coolest or most exciting and have fun!

 

[Niels]

Sound like you are afraid to remove the training wheels

 

[Rayek]

I am currently making the switch to an alternative game engine which is quite different compared to GMS, and from my perspective steps to take to actually learn working with a new engine would be:

- do a couple of essentials tutorials to get up to speed quickly in so far as to get your bearings: the overall engine's feel, workflow, and advantages and caveats, asset workflow, project structure. No more than two weeks or three weeks of these. This is the more conceptual stage of learning. Get a bird's view of the engine. Not too many details. Play with existing game demos, or open sourced games which use the engine.

- do one or two small game tutorials, and start adding your own stuff and enhancements after finishing them. Don't take longer than a couple of days doing this. Expand basic game play, add your own custom GUIs, enemies, etcetera. Have fun. Break things. But be sure to use GIT for versioning in case things break to the point of no return. Try again if it did break. Add single-minded focused enhancements, like improving the animation of the main player character, polishing the Game Over code and visual effects. Start exploring the unique features of the engine, and learn to use the base components well. While you do this, questions invariably come up how to achieve certain effects and behaviours. Documentation becomes your best friend.

- Create two or three very basic games. Remake some classics like Space Invaders, or simple 8bit games. Only use the documentation as a reference. Learn to read the documentation and function reference. Don't worry about assets: get them from opengameart, or use existing assets you already have. The point is again to have fun exploring the engine. Try to code and structure the projects as cleanly as you can.

- Next, start your first larger project. Not too big. Ideally a month-long project for work (I did), which forces you to finish it. Try to structure it well, but don't over-design. Things will be messy. Next time you will do better. Just get it to work, and out of the door within the allotted time line.

But really, you gotta force yourself out of the tutorial zone. I always start a game's structure on paper, adding elements and breaking down things into easily-digestible chunks. Don't attempt to do it all in your head. Get a working prototype up and running within a week: just the basics so you know what to expect (more or less). If you cannot complete a basic prototype within a week's time, it's probably too big in scope for you anyway. Think smaller, and try again.

And start thinking in terms of game structure and play structure. In particular with strategic board games you probably want to map out the exact game play structure, and create flow diagrams, which can then be converted to code parts. Never try doing it all in your head. Write down things, and relate these things to game engine functionality.

It's also a good idea to keep a junkyard test project on the side of any game project to quickly test out things separately from the main project you happen to be working on. When in doubt how to achieve something, switch to the junkyard, and wreak havoc for an hour, or so. Test things, and when you have a working solution, implement it cleanly in the main project.

Jot down notes and comment the heck out of your code to keep track of why you did things. And to understand how things work when returning to a project later for code re-use.

Anyway, that's how I tend to work, and how I am learning this new game engine.

 

[Niels]

I am currently making the switch to an alternative game engine which is quite different compared to GMS, and from my perspective steps to take to actually learn working with a new engine would be:

- do a couple of essentials tutorials to get up to speed quickly in so far as to get your bearings: the overall engine's feel, workflow, and advantages and caveats, asset workflow, project structure. No more than two weeks or three weeks of these. This is the more conceptual stage of learning. Get a bird's view of the engine. Not too many details. Play with existing game demos, or open sourced games which use the engine.

- do one or two small game tutorials, and start adding your own stuff and enhancements after finishing them. Don't take longer than a couple of days doing this. Expand basic game play, add your own custom GUIs, enemies, etcetera. Have fun. Break things. But be sure to use GIT for versioning in case things break to the point of no return. Try again if it did break. Add single-minded focused enhancements, like improving the animation of the main player character, polishing the Game Over code and visual effects. Start exploring the unique features of the engine, and learn to use the base components well. While you do this, questions invariably come up how to achieve certain effects and behaviours. Documentation becomes your best friend.

- Create two or three very basic games. Remake some classics like Space Invaders, or simple 8bit games. Only use the documentation as a reference. Learn to read the documentation and function reference. Don't worry about assets: get them from opengameart, or use existing assets you already have. The point is again to have fun exploring the engine. Try to code and structure the projects as cleanly as you can.

- Next, start your first larger project. Not too big. Ideally a month-long project for work (I did), which forces you to finish it. Try to structure it well, but don't over-design. Things will be messy. Next time you will do better. Just get it to work, and out of the door within the allotted time line.

But really, you gotta force yourself out of the tutorial zone. I always start a game's structure on paper, adding elements and breaking down things into easily-digestible chunks. Don't attempt to do it all in your head. Get a working prototype up and running within a week: just the basics so you know what to expect (more or less). If you cannot complete a basic prototype within a week's time, it's probably too big in scope for you anyway. Think smaller, and try again.

And start thinking in terms of game structure and play structure. In particular with strategic board games you probably want to map out the exact game play structure, and create flow diagrams, which can then be converted to code parts. Never try doing it all in your head. Write down things, and relate these things to game engine functionality.

It's also a good idea to keep a junkyard test project on the side of any game project to quickly test out things separately from the main project you happen to be working on. When in doubt how to achieve something, switch to the junkyard, and wreak havoc for an hour, or so. Test things, and when you have a working solution, implement it cleanly in the main project.

Jot down notes and comment the heck out of your code to keep track of why you did things. And to understand how things work when returning to a project later for code re-use.

Anyway, that's how I tend to work, and how I am learning this new game engine.

I just wish the other engines had manuals that were as well written as GMS%)

 

[Sabrina Stoakes]

Honestly this is where project management would come in handy, I think. I learned how to better structure a project when I had to take a project management class in college. You could easily google how to start a project and take advice from it.

As for starting the project, usually what a lot of the people I know (me included) do is set up a test room before making anything else and program all the game's mechanics and test them in that room. Now you can make changes later, but I feel like this is an important step that way you've got everything working as smoothly as possible before you start getting into some serious programming.

Most importantly though, don't feel like you can't ask for help! You've got an entire active community at your finger tips, so make good use of it, and follow those community guidelines to stay outta trouble.

 

[Rayek]

True, having a helpful community can be incredibly nice to have. Be forewarned though: don't use the community as a crutch, and always try to solve the problem by yourself first. It will grant you valuable insights, even if you fail (especially if you fail!). And it creates a frame of reference for the community's members how to help you best.

 

[mkyprice]

Try making a few dummy games and get comfortable with the environment before moving on to your dream game. I must have made about twenty plus projects before moving on to anything halfway decent. It gives you a good idea of where you feel comfortable starting with a project. For me, I usually create a player, get some okay movement, add an enemy, etc. Make a bit of progress and you'll see it come together before you know it.

A great tutorial and follow along if you haven't already seen it, is Tom Francis:
https://www.youtube.com/user/Pentadact

He has wonderful insights and tutorials.

 

[Sabrina Stoakes]

As a general rule, don't create menus and splash screen until you need them. You are going to be restarting your game thousands of times as you work on it, do you really want to code those first just so they can slow you down?
Same thing goes with large audio files or audio files in general.
Basically you want your game to compile quickly and be in the game room working as fast as possible in the beginning.
That should narrow down your options of where to start. Other than that, just start building a foundation. If you built a house would you start with the roof?

This is fantastic advice. I used to make the mistake of adding sounds to my games too early and it would get so annoying when trying to test stuff haha

 

[Niels]

I'm actually against that advice...
IMHO it's better to make a few really small games from start to finish (adding a title screen,sounds and music, and a win/lose state) and compile and release them on itch.io.
That way you learn and improve on all aspects of game making, and you developing a sense of scope, instead of learning how to start and drop projects.