Coding order and your preference?

SteveZX81

Just pondering something and I'd like to see what other people do.

When you start on a Fuze game do you always code things in the same order.
like: menu screen then level 1 then level 2-whatever, then game over screen etc.

or does it change? so one game you might start with the menu screen and then level 1 of the game and the next time you might start with level 1 of the game and then the game over screen?

So, do you stick to a pattern or random and have you tried doing it other ways, did it not work out or what?

PickleCatStars

I always start with the main loop of whatever I’m doing. I rarely get as far as a ’game over’ screen or a start screen and have only ever once had all 3, in the last game jam.

Martin

I’d tend to agree. I tend to start with the main loop. I’m not convinced it’s the right thing to do, but it’s generally my approach. I do this because my first port of call is usually to try and implement some mechanic or other and then provided I can get that to work I tend to take it from there.

spikey

Interesting question. Main loop, so, same here, but did not question it yet to much, because I just want to find out how an idea works or it looks like. This could change, if I will start a project one time 🤔, and a) I already did that style of game once and b) I have code to re-use for every general functionality
so, right now it's:

main loop and when I start duplicating code or do a very specific part, that I already know will anyway land in a function, I create a function
title screen (suddenly I invest more time here than in the game, or it feels like this)
game begin/end rules
cheap game over screen
loading screen
menu
fix major issues
high scores
improve game rules
thinking about doing a better game over screen, but skipping it again
fixing new or not encountered major issues

Everyone, thank you for sharing your workflow.

xevdev

Yeah me to.
Main loop.
And after I'm satisfied that's working.
Game states.
Then main loop
Then it's rewrite some element for speed or aesthetics
Usually don't worry about sprites have placers until I'm more into what I need.
Might put a track in the background about now
Start working on levels
Get board
Find something else shiny to work on
Never come back
Only completed 2 games.

waldron

Throw a loose framework up of all states of the game, start screen,main play loop and end/game over.
Then I start on the level/rounds and evolve the build from there.
The first level of a game usually starts with a new function or effect/style which will also evolve throughout.
If I find myself lagging during a build I then think if I start a new program/game what would I do, then try and incorporate that idea into level 2.

AndyG1985

I’m the same as Martin - I start with the main loop and the main mechanic (usually how the player moves) then add the functions as needed. Next to last, I add analogue controls for people who prefer them, then last thing is the start screen.

As I’ve only done 4 projects over 8 months, I always find I’ve forgotten the basics of the main loop. Update then updatesprites? Or vice versa? Gah what did I do last time?!

SteveZX81

Thanks everyone. I've been struggling with my latest game. It seems to be one step forward and six back but I think it's because I'm doing a little on this and a little on that and not focusing on a plan of attack. I think this will help me plan things a little better.

PB____

Before creating a game. I first consider the idea I want to make. I think about a complete picture of my game, so I can consider what direction I want to take the implementation. Do I want to use sprites or not? Should I use 3D? What type of structures may I need? Of course the idea may adapt during development, but it's good to start with a plan that motivates you.

I consider if the plan is something I can complete, and if it's something I want to spend my time on.
Then I start my project.

For my games (excluding game jam entries) I've created a template project with the things I expect to need in most of my games (menu's, loading assets, handling input, displaying credits, storage, processing data).

That template is far from perfect, and a lot should be improved. But by reusing that template for each new game, it prevents me to solve the same problems over and over again. And I can gradually improve my template code to make it better where I need it for functionality (to also improve my future projects).

So to get started, I only need to change a few variables (like the game name and version) and I have a complete menu for my game. And it's inviting me to create the actual game :) And I already feel familiar with the approach, since it's in part a copy of my previous project.

Using this approach does have some draw backs, because it gets harder to change choices you've made in the past about the generic stuff (like how to handle input). And it gets more likely to have "dead code" (functions that are never used) in your project. So this approach is not for every project, and not for everyone.

But if you tend to get stuck on the first few lines of code, then this might be an approach that helps to get started. It also makes your projects feel more familiar, because things like menu's are similar across your projects.