• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

Indie Game Development Discussion Thread | Of Being Professionally Poor

Status
Not open for further replies.

Blizzard

Banned
So I have to do a final year project for my course and I’ve decided I want to have a shot at making a game. My initial idea was to do a shoot-em-up but in trying to do some research I’ve discovered I can’t get past the first stage in most of the horizontal ones. I have some programming experience but nothing game related.
What I want to ask is what genre’s could a beginner make a simple complete game of in the span of 9 months or so?
If you have the time to dedicate, you could probably make a simple puzzle/platformer/shoot-em-up game in a matter of a few weekends, let alone 9 months. It depends how complex the game needs to be, how much polish you put into it, etc. If you have a bunch of other classes and aren't using this as portfolio material, I would suggest you set the scope somewhat lower than you think you can handle, so then when you discover everything took longer than expected, it's ok. :p


More GUI thoughts...on one hand I'm of course reinventing the wheel, but on the other hand I feel like I'm making gradual progress, whenever I make myself work on it every weekend or two. I think one of my current challenges is the need to nail down a list of things I need to go forward with actual game design, so I don't get stalled forever by feature creep. Tentative list of immediate tasks left to do:

  • Support default/alternate graphical styles on buttons.
  • Support automatic text rendering on buttons so I can just provide a string when I create one, rather than having to manually edit the text for each button image.
  • Make GUI regions (my equivalent of popups or windows or frames) do a 2D offset before they start drawing their widgets, so that widget coordinates will/can be relative to the region, rather than absolute coordinates for the entire screen. This would allow me to move entire regions along with all their widgets by just changing the region position, instead of having to adjust the coordinates of the widgets as well.
  • Use my newly created GUI widgets and event handling to create...a GUI editor that helps me streamline the process of creating the actual game GUI. GAMECEPTION.
  • As part of that last item I would need to support a file format and I don't really want to use XML...but I'm putting off this step until when and if I actually get into the GUI editor. Scary.
 

Pietepiet

Member
So I have to do a final year project for my course and I’ve decided I want to have a shot at making a game. My initial idea was to do a shoot-em-up but in trying to do some research I’ve discovered I can’t get past the first stage in most of the horizontal ones. I have some programming experience but nothing game related.
What I want to ask is what genre’s could a beginner make a simple complete game of in the span of 9 months or so?

There's a lot of genres you can probably pull together in 9 months. Platformers, shmups, puzzle games, topdown dual-stick shooters.
I'd say anything arcady is your best bet. Come up with a simple mechanic to build your game around, add a leaderboard and you're set for a fun highscore game.

The one thing you need to watch is feature creep, though. Come up with a plan of action, and divide everything into MOSCOW:
- Must be done (for the game to be fun)
- Should be done (for the game to be really good)
- Could be done (in the time given (9 months here))
- Would be nice (if you have some extra time left)

Add every new cool feature you come up with during development into one of these groups (any new features you come up with mid-development would usually go to Would be nice, unless it's really important to make the game feel better). This'll help keep track of your scope and will hopefully prevent you from adding stuff to the game that you don't have the time for :)
 

Razek

Banned
Are you crazy? It seems to be almost finished and it looks way better than many indie games, finish it, at least you'll gain some money for your hard work!

Awesome work man, is it playable anywhere ? I love some of your art, especially the desert backdrops e.t.c , have you ever though about releasing it despite not being fully complete?

Thanks for the kind words. I can't work on it anymore. Actually, typing up that post made me queasy and I quickly ran away from this thread (hence the late reply). Anyways, nah, I'm done and it's way too buggy to bother releasing since there are a few crash errors I don't feel like hunting down. Thanks again though for the supportive responses!
 

Ashodin

Member
So tomorrow I dive back into the script for the game. I have to tighten it up so every scene is either serious, hilarious, or downright awesome.
 
Anyone here go to NY Gaming meetups? Going to check out my buddy Joe Kowalski's (graphic designer for Double Fine) game tomorrow night. Should be fun.
 

Feep

Banned
So, I'm not very good at programming, apparently. I'm trying to make my game really nicely object oriented, but I'm running into some issues. Notably the following:

I have an event handler class, which deals with when events fire and then takes appropriate action. The main class has an instance of the event handler, as well as many instances of "unit" objects. But from within the event handler class, how can I make any changes to any of the unit objects without literally passing every single one of them (an unknown, possibly very large number) into the event handler class? And even if I do this, I'll have to pass in nearly everything in the game: camera objects, map objects, blah blah blah.

What's the best way to go about something like this?
 

Tashi

343i Lead Esports Producer
NYC, midtown at the Microsoft building. Info here http://www.meetup.com/gaming/events/77732032/

It's too late to register for tomorrow but it happens every week, get to check out and perhaps show whatever it is you are working on to a group of people.

Wow. How cool. I live an hour upstate of NYC to taking a train down for one of these events here and there wouldn't be too much of a hassle. Definitely looks like a place to meet some great people, learn some things, get some inspiration and network. Awesome, thanks for the link.
 

Blizzard

Banned
I'm currently just using linked list data structures for things like widgets, and iterating over those when I want to send them events.

It may bite me later, but I figure it's a simple-ish approach for now.
 
So, I'm not very good at programming, apparently. I'm trying to make my game really nicely object oriented, but I'm running into some issues. Notably the following:

I have an event handler class, which deals with when events fire and then takes appropriate action. The main class has an instance of the event handler, as well as many instances of "unit" objects. But from within the event handler class, how can I make any changes to any of the unit objects without literally passing every single one of them (an unknown, possibly very large number) into the event handler class? And even if I do this, I'll have to pass in nearly everything in the game: camera objects, map objects, blah blah blah.

What's the best way to go about something like this?

First, you have to make a structure to contain you events. eg:

{
was_pressed: {button_a: true, button_b: false},
was_released: {button_a: false, button_b: false},
mouse_position: {x: 100, y: 250}
etc.
}

Then you have to create two of them, one "current" and one "buffered". Your event handler writes to the "buffered" one and your game object query the "current" one. Then in your game loop you do something like this:

- Substitute the "current" with the "buffered" event structure
- Create a new "buffered structure"
- Game logic, which querys the "current" event structure
- Draw
- Sleep

While in parallel your event handler is building the "buffered" structure for the next game loop.
 
Oh, did Feep mean he doesn't want to create lots of event objects? My bad in that case.

I think the problem is that the event handler has no business knowing about your game objects.

Also, unless you are making a fighting game, subframe input handling seems like a cause for problems. Your game logic should be contrained to you main loop. Having values of you objects changed by an event thread instead of your main thread seems like a trainwreck waiting to happen.
 

Feep

Banned
First, you have to make a structure to contain you events. eg:

{
was_pressed: {button_a: true, button_b: false},
was_released: {button_a: false, button_b: false},
mouse_position: {x: 100, y: 250}
etc.
}

Then you have to create two of them, one "current" and one "buffered". Your event handler writes to the "buffered" one and your game object query the "current" one. Then in your game loop you do something like this:

- Substitute the "current" with the "buffered" event structure
- Create a new "buffered structure"
- Game logic, which querys the "current" event structure
- Draw
- Sleep

While in parallel your event handler is building the "buffered" structure for the next game loop.
A decent structure, but it still means I have to technically deal with events from my main class, which I was hoping to encapsulate into the EventHandler class and leave it there. Oh well...looks like my main class is just getting bigger, that's all.
 
A decent structure, but it still means I have to technically deal with events from my main class, which I was hoping to encapsulate into the EventHandler class and leave it there. Oh well...looks like my main class is just getting bigger, that's all.

I'm not sure I get your point.

Every object in you game should have a tick() event which gets called once per game loop. Then in the definition of that tick event you query the singleton event structure and define your game logic. The main loop looks something like this.

Code:
main:
  replace_events_structure()
  for object in all_game_objects:
    object.tick()
  for object in all_game_objects:
    object.draw()

Then for example, you have a class to represent the player

Code:
class Player:
  def tick():
    if Events.current.was_pressed "right":
      move_right()
    elsif Events.current.was_pressed "left":
      move_left()
    if Events.current.was_pressed "up":
      jump()

  def draw():
    this.sprite.draw()
 

Feep

Banned
I'm not sure I get your point.

Every object in you game should have a tick() event which gets called once per game loop. Then in the definition of that tick event you query the singleton event structure and define your game logic. The main loop looks something like this.

Code:
main:
  replace_events_structure()
  for object in all_game_objects:
    object.tick()
  for object in all_game_objects:
    object.draw()

Then for example, you have a class to represent the player

Code:
class Player:
  def tick():
    if Events.current.was_pressed "right":
      move_right()
    elsif Events.current.was_pressed "left":
      move_left()
    if Events.current.was_pressed "up":
      jump()

  def draw():
    this.sprite.draw()
Well, I'm going to have over thirty event types, each with a unique "response"...and some of them are relatively complex. All of these responses are now going to have to be found and executed in the main game class, so they can modify everything they need to...something that I think fundamentally should be in the EventHandler class. I can try to encapsulate as much of the complex responses inside the specific classes the event is modifying, but it's not always that easy.

No big deal...I can do it...it just seems "anti-OOP" to me.
 
Well, I'm going to have over thirty event types, each with a unique "response"...and some of them are relatively complex. All of these responses are now going to have to be found and executed in the main game class, so they can modify everything they need to...something that I think fundamentally should be in the EventHandler class. I can try to encapsulate as much of the complex responses inside the specific classes the event is modifying, but it's not always that easy.

No big deal...I can do it...it just seems "anti-OOP" to me.

But you do it in the eventhandler class, you main loop is only responsible for switching the structure which holds the events of the previous loop(s). I suck at explaining xD

Of course it's just one way of doing it. You can do it whichever way you want.
 

Blizzard

Banned
I think the problem is that the event handler has no business knowing about your game objects.

Also, unless you are making a fighting game, subframe input handling seems like a cause for problems. Your game logic should be contrained to you main loop. Having values of you objects changed by an event thread instead of your main thread seems like a trainwreck waiting to happen.
My main thread loop includes event handling, possibly for simplicity. Otherwise I'd have to start splitting up logic and possibly causing synchronization issues, and I already have semaphores and so forth. I think I'll wait to see how it goes in an actual game, and whether I need event-handling in a separate thread. Unless you mean actual input reading, which is presumably done by SFML behind the scenes at the moment, possibly in a different thread.

I feel stupid trying to understand Feep's and BomberMouse's posts though, since I guess I don't fully follow the logic behind not saying like "pSomeObject->HandleEvent(pEventObject)" and having the event object contain whatever event-specific data is needed, which would be handled as needed by the individual game object code.
 

Feep

Banned
One way I think I could do it would be to make EventHandler a static class, and include code in every object (unit, camera, map, etc.) to check the handler for any relevant events, and then take specific action. It would mean constantly polling the EventHandler with every object every frame, though, as opposed to just once per frame in the main thread loop.

Oh well; thanks for the help. I just moved the EH code out into the main loop, no big deal. ^^
 
Wow. How cool. I live an hour upstate of NYC to taking a train down for one of these events here and there wouldn't be too much of a hassle. Definitely looks like a place to meet some great people, learn some things, get some inspiration and network. Awesome, thanks for the link.


Glad I could help, hope you can make it down one day.

I made a mistake above, by "every week" I meant month. Usually around the end of the month it happens. Also Microsoft building security requires the list to be finalized by the Friday before the event (hence why it's too late).
 

Margalis

Banned
Either poll for input or subscribe for messages / events / callback functions when an event that interests you occurs.

Are you talking input events or any kind of generic game event?

If it's just input events polling is often the most straightforward way, it performs fine and doing a whole lot on top of that can just obfuscate. If you are talking about logical events then you probably want some sort of publish/subscribe model.
 

Blizzard

Banned
One way I think I could do it would be to make EventHandler a static class, and include code in every object (unit, camera, map, etc.) to check the handler for any relevant events, and then take specific action. It would mean constantly polling the EventHandler with every object every frame, though, as opposed to just once per frame in the main thread loop.

Oh well; thanks for the help. I just moved the EH code out into the main loop, no big deal. ^^
I'm still a little confused about this -- why not have the EventHandler/main thread loop call some sort of HandleEvent method on each object, rather than having each object poll for events? That lets you have your events be OOP in an inheritance structure, and keep the event-processing code inside the game objects themselves. I'm assuming there are design reasons I don't understand.

I'm also guessing you can't give us an example of 2-3 of these events, since it would tell too much about the secret game you're working on. =P
 
One way I think I could do it would be to make EventHandler a static class, and include code in every object (unit, camera, map, etc.) to check the handler for any relevant events, and then take specific action. It would mean constantly polling the EventHandler with every object every frame, though, as opposed to just once per frame in the main thread loop.

Oh well; thanks for the help. I just moved the EH code out into the main loop, no big deal. ^^

That's exactly what I meant. Usually the objects that poll for input events are very few, so it should never be a problem.

I think I'll wait to see how it goes in an actual game, and whether I need event-handling in a separate thread. Unless you mean actual input reading, which is presumably done by SFML behind the scenes at the moment, possibly in a different thread.

Sorry I've never used SFML, but usually those frameworks run the callbacks for events on a different thread by default. So yeah, if you can do it sequentially in the main loop, that's better. Much easier to debug.
 

Feep

Banned
I'm still a little confused about this -- why not have the EventHandler/main thread loop call some sort of HandleEvent method on each object, rather than having each object poll for events? That lets you have your events be OOP in an inheritance structure, and keep the event-processing code inside the game objects themselves. I'm assuming there are design reasons I don't understand.

I'm also guessing you can't give us an example of 2-3 of these events, since it would tell too much about the secret game you're working on. =P
The events are generic...this unit gets close to this thing, the camera pans, a voiceover file plays. Anything.

The reason I can't call a method on some object is because the EventHandler class does not have the object. Passing in a reference is possible, but would need to be set up by the main thread loop, and in many cases I don't know the specific unit before the event occurs (what unit gets close to the thing?), so I would need to pass it, like, ALL the soldiers.

Code:
class Main
{
      Unit u;
      EventHandler e;

      e.readEventDataFromFile()

      mainUpdateLoop {
      .....
      }
}


class Unit
{
     public void DoStuffWhenEventHappens()
     {
     ......
     }
}

class EventHandler
{
     mainUpdateLoop
     {
         //Oh snap! Event occurred! The unit has to do that stuff!
         u.DoStuffWhenEventHappens() //Compiler error: what the fuck are you talking about
     }
}
 

totowhoa

Banned
Hey guys, I'm an artist and I've thought it would be a lot of fun to try my hand at pixel art. Is there any good dedicated software out there that you all could recommend? I'm kind of interested in designing some sci-fi / cyber punk worlds in pixel form for some reason, and it seems like a really fun medium to try out.

I have software geared more towards painting and illustration, so I know that could suffice, but I was wondering if there's more focused software.
 
Hey guys, I'm an artist and I've thought it would be a lot of fun to try my hand at pixel art. Is there any good dedicated software out there that you all could recommend? I'm kind of interested in designing some sci-fi / cyber punk worlds in pixel form for some reason, and it seems like a really fun medium to try out.

An older thread links to a bunch, but off the top of my head I like ASEPRITE.
 

Blizzard

Banned
That's exactly what I meant. Usually the objects that poll for input events are very few, so it should never be a problem.

Sorry I've never used SFML, but usually those frameworks run the callbacks for events on a different thread by default. So yeah, if you can do it sequentially in the main loop, that's better. Much easier to debug.
I'm doing GUI stuff at the moment so I'm probably dealing with mouse events more than I would normally be (actually maybe not since there would be lots of clicking in my game).

But yes, my main game loop goes something like this:

Code:
While there are more than my fixed step length of time left to process:
   Poll the GUI framework (SFML) for input events until there are none left
      (and for each event, create my own internal non-SFML event object,
       pass it to the GUI, then to any input handler objects I have registered)

   Update GUI state for fixed step length
   Update game state for fixed step length
End While

Interpolate actors if needed, for smooth motion

Draw game stuff

Draw GUI

Hopefully I summarized it properly and didn't miss anything...it's been some time since I constructed the loop itself, so I was trying to outline from looking at the code. :p
 

Blizzard

Banned
Hahaha...thanks to Feep for asking about this since I think I just learned some stuff.

First, I was using 1/60 second as my fixed time step for input sampling and state updating. I think I'm going to change to a 1/120 second step, since I THOUGHT I had been getting some slight input lag, and I think with my game loop it makes sense -- sampling more often means you are more likely to process input events right before rendering for that frame (when locked to 60 fps with vsync for instance).

Now the very funny thing is that to test the input lag thing, I changed my fixed time step to 1/3 second. This added a ton of input lag as expected, if you click at the wrong time, but hilariously I'm guessing (hoping?) I had interpolation active on certain actors, since the huge background image I was using did this very smooth zoom to full size motion. I think it was interpolating the scale from 0 to 1 over the 1/3 of a second interval. It was cool to see that worked, though I never intended that particular use case. :p

*edit* Actually, apparently my background SHOULDN'T be an interpolating actor, so I need to look into that. Either way it was a good find, along with the input lag reduction.



Feep, looking at your pseudocode example, I still think you could have a single main loop handle checking for events and distributing the events, but if you want all objects to be able to asynchronously send and receive their own special events to each other, then yeah you may need something more complicated (and potentially thread-synchronized if you end up using multiple threads). At the least you would presumably need a synchronized queue, or a queue of "pending events" that will be sent out the next time through the main game loop.

Each game object could implement HandleEvent(GenericEvent* someEvent), and each GenericEvent could have a GameObject pointer inside it as a destination, and the main thread could simply call HandleEvent on the destination object, with the object as a parameter.

Maybe. :p
 

Feep

Banned
Feep, looking at your pseudocode example, I still think you could have a single main loop handle checking for events and distributing the events, but if you want all objects to be able to asynchronously send and receive their own special events to each other, then yeah you may need something more complicated (and potentially thread-synchronized if you end up using multiple threads). At the least you would presumably need a synchronized queue, or a queue of "pending events" that will be sent out the next time through the main game loop.

Each game object could implement HandleEvent(GenericEvent* someEvent), and each GenericEvent could have a GameObject pointer inside it as a destination, and the main thread could simply call HandleEvent on the destination object, with the object as a parameter.

Maybe. :p
I know! I moved the handle-y handle stuff out to the main loop, so it can access and direct all game objects according to event data. I was just wondering if there was a way I didn't need to do that, I guess. = D

Sidenote for funsies: are a lot of you guys actually and intentionally dealing with multi-threaded game programming? Because that's just terrifying to me. ; ;
 
Hey guys, I'm an artist and I've thought it would be a lot of fun to try my hand at pixel art. Is there any good dedicated software out there that you all could recommend? I'm kind of interested in designing some sci-fi / cyber punk worlds in pixel form for some reason, and it seems like a really fun medium to try out.

I have a software geared more towards painting and illustration, so I know that could suffice, but I was wondering if there's more focused software.

Eh, I just use Photoshop.

<--------
 

Bentles

Member
Hey guys, I'm an artist and I've thought it would be a lot of fun to try my hand at pixel art. Is there any good dedicated software out there that you all could recommend? I'm kind of interested in designing some sci-fi / cyber punk worlds in pixel form for some reason, and it seems like a really fun medium to try out.

I have software geared more towards painting and illustration, so I know that could suffice, but I was wondering if there's more focused software.

I use Paint.net for this and it's brilliant but I'm actually looking for a bit of an upgrade. I need a better tool for animating my sprites. Up to now I've been using the game to test them and that's fine when they turn out well but incredibly slow going when I need to tweak stuff. Does anyone know of anything good? I'm not a fan of aseprites GUI but I'll use it if it's my only option.

EDIT: Graphics Gale looks interesting
 
I know! I moved the handle-y handle stuff out to the main loop, so it can access and direct all game objects according to event data. I was just wondering if there was a way I didn't need to do that, I guess. = D

Sidenote for funsies: are a lot of you guys actually and intentionally dealing with multi-threaded game programming? Because that's just terrifying to me. ; ;

Nah, there's no reason for an indie dev making a game to do multithreaded gp. Performance is not a problem. You should only do it when you are dealing with web calls so that they don't block the main loop.
 

totowhoa

Banned
I find Photoshop to be awful for pixelart. I use GraphicsGale every day for work.

http://www.humanbalance.net/gale/us/

It's cheap and geared specifically towards pixelart and animation. Interface takes a little getting used to, but feel free to hit me up with any questions :)

Now that looks much closer to what I was looking for! Thanks. The youtube video I just watched looked really great, and I don't mind figuring out a new interface... I'm used to expecting a steep learning curve when I'm dealing with something new. Yeah, I love PS for illustration and design purposes, but it seems like it would be a pain to use for pixel art.

I'd still love to hear some other recommendations... I'll probably post some of my pixel art in this thread later as well. It'll be the closest I get to game development for some time until I graduate soon and can devote more time to it. I figured if I wanted to start dabbling in the hobby, I should start with pixel art, since art is already my strength.
 
The reason I can't call a method on some object is because the EventHandler class does not have the object. Passing in a reference is possible, but would need to be set up by the main thread loop, and in many cases I don't know the specific unit before the event occurs (what unit gets close to the thing?), so I would need to pass it, like, ALL the soldiers.

have something like a UnitManager so your EventHandler can lookup for units
 

Margalis

Banned
Nah, there's no reason for an indie dev making a game to do multithreaded gp. Performance is not a problem. You should only do it when you are dealing with web calls so that they don't block the main loop.

What if you are making a game that requires high performance?

Modern computer architecture is moving towards a large number of cores, it's really worth people's time to learn how to utilize them effectively.
 

Bamihap

Good at being the bigger man
CF48A8C0ED97B9C819A140F84B37C3016FC1A2CA


A new screenshot from Castaway Paradise. Hope you like it.
 

Kritz

Banned
So, here's my progress on the game I've been working on for the past few months. I don't get a lot of time to work on this game, so I'm trying to simplify my milestones for this project. I want it to be completed at around about the same time that my current uni semester finishes, which gives me a month or two left at this stage.

Vlander Build 14


At this point I consider the first level feature complete. I am going to add one or two more levels, and then I will consider the game content complete. Finally, I aim to polish up the menus, add credits and a help section. Then I will add sound effects. At that point I will consider the game complete.

For now I am ignoring most bugs in the game, for sake of actually completing this project instead of getting stuck on small details.

I may add in a (long)jump mechanic, as it would be simple to program, and would increase the possibility space of the game substantially.

Controls:
WASD - Movement
Space - Mantle blocks
Mouse1 - Pick up blocks

Goal - Reach the end of the level.
Optional - Reach the end of the level with the boxfuck (the glowy green cube. Named after a game I made over a weekend to make my friends hate me).
Optional - Find the easter egg.

Known bugs:
You can mantle into geometry
Mantling while holding physics objects fails in conditions where it looks like it should succeed
Physics objects can be placed in situations where you can never recover them
Physics blocks noclip through everything (not so much a bug as a workaround for a different bug)
Game doesn't release the cursor when you return to the main menu
Game doesn't capture the cursor when you click back into the game (only when you press "resume" in menu)

As usual, criticism is encouraged. I'm kind of just making this shit up as I go along because I have no financial obligation to succeed; the only reason I'm doing this is to make stuff that people find entertaining.
 

beril

Member
I know! I moved the handle-y handle stuff out to the main loop, so it can access and direct all game objects according to event data. I was just wondering if there was a way I didn't need to do that, I guess. = D

Sidenote for funsies: are a lot of you guys actually and intentionally dealing with multi-threaded game programming? Because that's just terrifying to me. ; ;

I'm kind of in the same camp. It's always seemed like a massive extra complication that I just don't want to bother with regardless of the benefits. I'm the same way with network code; never really tried it but I can imagine it requiring some massive changes to the way I write my code so I've strongly opposed any network features in every project I've worked on. In my own games it's not a very big issue anyway since I'm not very keen on online multiplayer. But I'm a pretty shitty programmer when it comes to technical stuff and to writing clean adaptable code.
 

Blizzard

Banned
I know! I moved the handle-y handle stuff out to the main loop, so it can access and direct all game objects according to event data. I was just wondering if there was a way I didn't need to do that, I guess. = D

Sidenote for funsies: are a lot of you guys actually and intentionally dealing with multi-threaded game programming? Because that's just terrifying to me. ; ;
Multithreaded stuff isn't terrifying to me per se, but probably because I abuse semaphores if I'm worried about it. I actually use semaphore- (or mutex)-protected linked list data structures even though I probably don't need to worry about it, since my engine is single-threaded as far as I know, besides whatever SFML does in the background to get input events.

Optimizing for multiple core processors could be interesting, but if I program it right the game I'm working on should never get to that level of complexity I -think-. :p AI might be the one area where I could optimize with multiple threads. I went through some neat training for work recently regarding optimizing applications for multiple cores, and how things can scale (or not).
 

robin2

Member
Is there an engine to easily make a turn based tactical game like Ghost Recon: Shadow Wars (but completely 2D with fixed camera like Advance Wars)? I don't anything about programming.
 
You'd be able to use GameMaker for something like that and do it pretty quickly, but it would require learning the GameMaker Language and getting familiar with the tools.

I'd suggest starting with a little something less ambitious,and without programming experience something like GameMaker or another complete solution would be your best bet.
 

Blizzard

Banned
Well, I figured out why the background seemed to be moving and stuff was scaling when I turned the number of updates per second waaaay down (e.g. 1 per second as a test).

All of the enemies and the main character are set to interpolate. Since each actor starts at position (0, 0), and I immediately moved them to their initial locations, they were getting interpolated for the very first second, which made for a funny effect. The REALLY confusing effect was the background looking like it was moving...which was apparently because I had the camera following the player character (centered), so as the player character interpolated from (0, 0) to the correct position, the background appeared to be zooming by behind it.

At any rate, with some small measure of foresight I had long ago added a method that would let me update an actor's previous state to match the current state (meaning that no interpolation will be done until further updates). So, simply calling that after setting up each initial actor position seems to fix things at low update rates, and everything is as you would expect, with things smoothly animating and drawing at 60 fps or whatever while updates and input handling are at a horribly slow 1 per second, haha.

Now that I think I understand things, I jumped the update rate up to 120 per second, and I will use that from this point on in an effort to keep the user interface responsive. :p

One annoying thing that came up again is the eternal SFML vsync issue, where every once in a while I will get stuck at 30 fps, or stuck (tonight) at 24 fps. I am nearly convinced this is due to some sort of timer/sleep mechanism inside SFML that occasionally ends up at a weird resolution. I don't want to try to update to the latest SFML version since I changed at least one SFML library thing, and I'm afraid they might break things on me, but I do wonder if they fixed that in a later version.

Very weirdly, resizing the window a few times seems to typically restore the application back to 60 fps vsync'd. And I'm pretty sure it's not a performance thing, since it goes over 2000 fps withou vsync. :p
 

alstein

Member
http://positech.co.uk/cliffsblog/

Going to recommend this guy's blog to some of you guys. He's a pretty successful indie dev, also does showmethegames.com if you guys want publicity (you need to sell direct as an option to do so, not just be on a portal)

Lots of insight about how it is for indies and his own recommendations for success.
 

neoneogaffer

Neo Member
ActionScript can be cool, but I have a bad attitude about Flash and Adobe AIR for two reasons:

1. Actually making vector graphics, staged animation stuff, and so forth seems really expensive because of the full Adobe software (and I am not a student). I think the UDK Scaleform UI stuff supports a more inexpensive option, but I'm not sure if the other option works with all the fancy widgets. One option might be Inkscape exports loaded into ActionScript, if you don't need animation stage stuff.

2. Perhaps more importantly, Adobe AIR seems rather reknowned for having some hated applications written with it. The one I am most familiar with is the Riot League of Legends client, which tends to have all sorts of random glitches, crashes, bugs, or whatever. Yes this happens with any software, but it just seems worse and more bloated with the AIR one...even if that's purely perception. :p

You don't have to use vector graphics. You can take a sprite sheet or a bunch of bitmap images and put them together like a flip book. All the development tools I use are free.

I can understand that AIR may not have been stable before. Personally I don't have any experience with stability issues on AIR on the app I'm working on. However, I expect AIR is more stable than before. Adobe is always updating AIR, so maybe the problems have reduced or gone away by now.
 

razu

Member
http://positech.co.uk/cliffsblog/

Going to recommend this guy's blog to some of you guys. He's a pretty successful indie dev, also does showmethegames.com if you guys want publicity (you need to sell direct as an option to do so, not just be on a portal)

Lots of insight about how it is for indies and his own recommendations for success.


Great site. Nice find. Thanks! :D

I like the bit on 'startups' :D
 
Status
Not open for further replies.
Top Bottom