the evolution of a löve application

[xjermx]

While every programmer might have a different approach, and every application might have its own path, I'm curious to hear how people tackle smallish löve applications. Every project starts somewhere, and then is built upon and built upon. What's the first small milestone (a static welcome screen, or perhaps some kernel of core gameplay) What is your approach?

[Robin]

For me, it really depends on the project.

[xjermx]

For me, it really depends on the project.

Give me some examples

[Robin]

Sometimes, I start with the menu. I did so with Invader, if I'm not mistaken.

When I was working with Ryne on Simon, I started on small animation and character movement tests.

With Space, I think I started with the "real" game right away.

[josefnpat]

I usually think of all the different states and libraries I want for the game, and then use a little script I wrote called loveskeleton. Then I just choose the state/library that would bring the game closest to being playable(e.g. menu and credits are usually the last of the libraries). Once I reach a playable state, then I start adding extra stuff and polish.

Here's how I did the LD23 in 13.5 hours.

[Inny]

I've heard the term "Tracer Shot" used to describe application building, where you have some high level vague idea of what your program should be, so you write the code necessary to at least get in and out of every one of those high level states. For instance, you know you need a title screen, you know you need a gameplay mode, you'll probably need the game over screen, and the high score screen, and maybe a credit roll screen. So, you make each of those in a cheap-ass way using the lamest way possible to transition modes (pressing the function keys for instance).

Of course, with gaming, the gameplay mode or modes are the most important code you write, so all of that other stuff is really just getting shit out of the way.

[T-Bone]

My current game got started with a class library. Then I made some framworks for game objects, text buttons and some other stuff. Then I made a state system, and made a menu and the in-game state, and started working from there. Then a level editor came into the project pretty soon.

[racarate]

I'm new to LOVE (and game-making in general), but I tend to go down a wikipedia rabbit hole (esp. for game jams, e.g. the theme) and then down a graphics rabbit hole and then sort of free-associate from the theme-guided graphics experimentation into some sort of mechanic.

This is what I got so far:

http://globalgamejam.org/2012/phoenix-n ... palindrome
http://www.ludumdare.com/compo/ludum-da ... &uid=10426

This method is a little shaky in that you can easily get distracted by theme research and graphics playing and end up with not much mechanics-wise, but I'm kind of trial-and-erroring myself through... this stuff.


-Nick

[Petunien]

I usually start with a game-concept, like the logical construction and course of game written in a OpenOffice Draw Document.
Also with a feature list and the function of each feature.

I think, having a plan is a important thing in game "developement".

[StoneCrow]

Im always thinking about the players interaction, wanna try and get something i can mess about with as fast as possible and upgrade the prototype.
So the first thing i generally get into my code is all my mouse.pressed and keyboard stuff then i start working on menus and the vague feel of the game. Once thats done i always get dragged for days into backend code and eventually emerge ready to work on some visual and gameplay stuff a week or so down the line.