LÖVE

Hello All,

I'm working on a fullscale* game in LÖVE, and I've reached a point where I'm unsure what do next. I'm also unsure who to turn too to help me, but I'm guessing many of you will have experience both with LÖVE/Lua and game programming in general, so, if you could please guide me, I'd be very grateful.

* Fullscale as in more complex than a simple arcade/demo style thing.

Now, before I discuss my concerns, let me give you some background on my game, and what I have developed so far.

The game is a 1-4 player fighting game. It features a variety of characters that are distinct and have special abilities, as well as stages that will have unique properties. (What I'm trying to get at, is that it's gonna call for quite a bit of custom code in each part.)

Now, so far I have implemented and more-or-less tested thoroughly:

• - a state manager (similar to the one in the HUMP library, but has stack capabilities, to allow multiple states to run at once.)
  - a screen/resolution manager (allows my game to run at any resolution, and automatically adds letterbox bars.)
  - a simple animation library (Not grid-based (to support unequal sized sprites), handles updating animations globally so they don't need each need an update method, compatible with love.graphics.draw())
  - A simple camera (supports zooming in/out, and parallax scrolling)

I'm also using a few of your awesome libraries too: TESound, TLTools, bump.lua, tween.lua

(NOTE: I think that's everything, but I don't have the source code in front of me, so I might have forgotten something...)

Also, all of these modules are more or less independent of each other (which is a good thing.)

Now, my problem is how I'm gonna get all of this to work, namely what direction I need to go with levels, and implementing the various entities in my game. Although I have a lot of general programming experience, I've never worked on a big game, and so I'm afraid I'm gonna screw up the design and end up with a hacky monster that will go down in flames before the world ever gets to see it.

I'm looking for few things really: 1) A tried and tested design that is clean & elegant, as well as flexible and able to be extended. Surprisingly very little of this is taught in game programming books (at least the few that I've read), generally due to breivity, so I know it's a lot to ask, but if you could share your experiences, and designs, especially if you've designed similar games. What were some of your best decisions when it came to interfacing different parts of your game, and why? Are there any more developed frameworks that run on top of LÖVE that I could study or modify? 2) Organizational tips. This will of course be part of the design, but how should I divide and organize all of this code, without it becoming a big sludgeball? (NOTE: I'm not used to Lua--being a C guy myself--and so I feel I might get too relaxed or something...) 3) Advice on how I should implement specific parts of my game. These are the main points that come to mind:

• - How to represent levels. Should I use a level editor? Levels will be fairly simple (e.g. a ground, & perhaps one or two solid platforms), they don't scroll much.
  - Depending on how I manage my levels, how should I load all of the data (e.g. What system will I use to know when to load Level A, and when to load Level B? How much information should be passed to the level loader?)
  - I was planning on using several gamestates at once to divide things up. Example: In a typical stage I might have a background state that just draws the static background (which would be an array of 100 256x180 images), a medium background state that perhaps would be animated (e.g. birds flying by, traffic, background stuff that depends on context.), a player state that controls and renders the players' sprites, AI states that control the CPUs. I'd also needs states for platforms, score keeping, etc. Anyways, is this a reasonable system? It makes each state fairly simple, but IDK...
  - How do I get all of these states to communicate? (e.g. player-state hit CPU-state, CPU-state needs to lower HP-state, and increase score-state, etc.) My state manager has basic global messages (e.g. setGlobalData()/getGlobalData()), but even this is messy. Is there a better way?
  - Like I mentioned above, this is going to call for a lot of custom code, for each character, level, etc.,. For example, Character A might be have combos X, Y, Z, but Character B might have combos A, B, C. Every character is playable by both the player and the computer (at different difficulties), so code-reuse is optimal here. How would I manage all of these things?
  - I plan on using a slightly enhanced version of the AI method described here: http://gamedev.stackexchange.com/a/33576 It seems fairly straightforward, but would I make it a general module, or would I need character specific AI to choose the right moves.

(That's all I could think of at the moment. I might have more later/as I progress. As more stuff comes up, should I put it all in this thread or make new threads? (I don't wanna spam. )

Well, that's just about everything. I really hope I made myself clear, since even I'm having a hard time explaining it to myself. (Don't hesitate to ask me to clear something up!) Anyways, I don't want someone holding my hand at every step, but at the same time I'm so overwhelmed I can't even take a step yet. I'm sure, a more experienced developer is snickering over how simple all of this truly is, but when one's never done it before, it just tends to be daunting, if ya catch my drift.

Thank you all in advance. I will be very grateful for any help at all.

Hi. Firstly, I would like to say that trying to architect a game from top down is a bad idea unless you have a lot of experience and have already designed several similar games. I've never made a fighting game myself so personally I would go about it from the bottom up - I would make the simplest playable prototype (placeholder graphics, no sound, no ai, no animations and so on). This prototype would be as barebones as possible and playable by 2 human players (again, no real ai yet). Next, I would make small incremental changes that introduce the other primary gameplay features (starting with basic ai) while being careful to keep modules as decoupled as possible.

thecodingotaku wrote:Now, so far I have implemented and more-or-less tested thoroughly:

• - a state manager (similar to the one in the HUMP library, but has stack capabilities, to allow multiple states to run at once.)
  - a screen/resolution manager (allows my game to run at any resolution, and automatically adds letterbox bars.)
  - a simple animation library (Not grid-based (to support unequal sized sprites), handles updating animations globally so they don't need each need an update method, compatible with love.graphics.draw())
  - A simple camera (supports zooming in/out, and parallax scrolling)

With this approach you're going to find yourself in the uncomfortable situation of thinking 'ok, so how am I going to make use of these features?'
The problem is that, you've ALREADY spent time doing all this work.
Suppose that you later find a very simple and elegant way of handling animations or you decide that the moving camera is unnecessary... oops, now you can't use the better/simpler approach because you already have a library which does that...
What I'm trying to say is, it's not a good idea to program features BEFORE you are actually going to use them.

- How to represent levels. Should I use a level editor? Levels will be fairly simple (e.g. a ground, & perhaps one or two solid platforms), they don't scroll much.
- Depending on how I manage my levels, how should I load all of the data (e.g. What system will I use to know when to load Level A, and when to load Level B? How much information should be passed to the level loader?)

I wouldn't worry about content until you have all the gameplay figured out including ai and it looks like your prototype is worth perusing.
Your first goal should be trying to make a fun, playable prototype with no content whatsoever.
I've abandoned a lot of prototypes that seemed fun in my head, but turned out to have bad/mediocre gameplay.
Also, producing content early on makes it harder to abandon/modify your game ideas.

haha i was about to write a big long response to this when i noticed it was basically the same as the one ivan already gave you .
good luck with your project .