C# Console Game Questions

[¨TrisT¨]

Hi.

I've started making a c# console game for fun.

I'm trying to do sort of a space invaders-style thing, maybe with online co-op.

 

But.

I have been using SetCursorPosition.

I'm gonna have to use threading.

Will calling SetCursorPosition at about the same time in different threads mess stuff up?

I take it I can't have multiple cursors, so if I call it in a thread and call it in another before an operation is complete,say, draw a character in an unwanted place?

After I do a write, if the cursor is "on top" of a character, SetCursorPosition will delete that character as it moves the cursor else where, is there a way to fix this?

 

Is there any better way to do this? I really feel like this is a dirty way to do it.

 

Thank you.

[DaBeggad]

why console tho... is it hard to learn c#

[¨TrisT¨]

3 minutes ago, DaBeggad said:

why console tho... is it hard to learn c#

??

Because I want to do it in a console, how else would you do it?

"is it hard to learn c#"

Really not trying to be rude but is that a question?

Do you think I'm trying to do it in batch?

Do you think I don't know c#?

Are you asking me wether it is or not?

[DaBeggad]

2 minutes ago, ¨TrisT¨ said:

??

Because I want to do it in a console, how else would you do it?

"is it hard to learn c#"

Really not trying to be rude but is that a question?

Do you think I'm trying to do it in batch?

Do you think I don't know c#?

Are you asking me wether it is or not?

sorry dude i thought you meant you wanted to create a game for consoles (xbox etc)... dont go apeshit bananas instantly... yes i wanted to know if its hard to learn compared to other program languages  

[¨TrisT¨]

1 minute ago, DaBeggad said:

sorry dude i thought you meant you wanted to create a game for consoles (xbox etc)... dont go apeshit bananas instantly... yes i wanted to know if its hard to learn compared to other program languages  

Depends on what you're comparing it to.

Easier than c/c++, harder than say vb, python or php.

I don't think a random thread is the place to ask that, there are many lying around with your answer.

[vorticalbox]

Yes, it will cause problems, I really suggest you learn some more on multi-threading before jumping right in. If you are doing a call in different threads you have no way of knowing when a call will happen or in which order.

[DaBeggad]

5 minutes ago, vorticalbox said:

Yes, it will cause problems, I really suggest you learn some more on multi-threading before jumping right in. If you are doing a call in different threads you have no way of knowing when a call will happen or in which order.

im learning java atm  

[¨TrisT¨]

6 minutes ago, vorticalbox said:

Yes, it will cause problems, I really suggest you learn some more on multi-threading before jumping right in. If you are doing a call in different threads you have no way of knowing when a call will happen or in which order.

Actually I think I may have the solution, I'll just make a multi-dimensional char array and change the stuff in there, printing it each "frame". What do you reckon would be a good enough "framerate"?

[vorticalbox]

10 minutes ago, ¨TrisT¨ said:

Actually I think I may have the solution, I'll just make a multi-dimensional char array and change the stuff in there, printing it each "frame". What do you reckon would be a good enough "framerate"?

 

I would first get your game running then make it multi-threaded later. There is a reason why most games out now don't use that many cores and that is because it is hard to get it right.

[Yamoto42]

Honestly...a console app would not be the best way to do it.  What you want to do wouldn't be hard at all using Forms...unless you're just wanting to manually manage a screen buffer for some reason.

[Nuluvius]

Without seeing any code it's hard to make any objective comments. However:

1 hour ago, ¨TrisT¨ said:

Will calling SetCursorPosition at about the same time in different threads mess stuff up?

This in particular makes it sound as though you have a bit of a train wreck going on... i.e. you are mixing view rendering and business logic together.

 

I would suggest that perhaps you may benefit from changing the way that you are thinking about your architecture. In concise terms; imagine that the console is just one of a number of different views or canvases upon which to draw. What you really want here is an abstraction in the form of some kind of rendering interface that hides away the specific implementation of what is being drawn to and how it's happening... All of your core game logic should happen completely independently of the rendering implementation and indeed you can thread this core game logic to your hearts content. In other words, the rendering implementation should be encapsulated, kept separate and as dumb as possible.

[Mira Yurizaki]

Why not draw everything in a buffer and make one call to draw it at once? Unless memory is huge concern here, this is a viable option.

[Nuluvius]

4 minutes ago, M.Yurizaki said:

Why not draw everything in a buffer and make one call to draw it at once? Unless memory is huge concern here, this is a viable option.

As valid a suggestion as it is, a buffer is a just an implementation detail. I'd be more concerned with the shape of the architecture first of all.

[¨TrisT¨]

1 minute ago, Nuluvius said:

As valid a suggestion as it is, a buffer is a just an implementation detail. I'd be more concerned with the shape of the architecture first of all.

I believe I'd said that already in a really dumb way.

2 hours ago, ¨TrisT¨ said:

Actually I think I may have the solution, I'll just make a multi-dimensional char array and change the stuff in there, printing it each "frame". What do you reckon would be a good enough "framerate"?

 

Thank you, still.

 

 

2 minutes ago, Nuluvius said:

As valid a suggestion as it is, a buffer is a just an implementation detail. I'd be more concerned with the shape of the architecture first of all.

Seems simple enough, make functions that take coordinates as arguments that draw the ships to the buffer.

Then I'll make functions to compare the "spaces" that the ship occupies to the ones of where the "bullets" are, sort of a collision checking function thing.

 

Now should I draw the ship every frame to a brand new clean buffer or "move" them, drawing it to the side and erasing previous stuff?

[Nuluvius]

3 hours ago, ¨TrisT¨ said:

Seems simple enough, make functions that take coordinates as arguments that draw the ships to the buffer.

Then I'll make functions to compare the "spaces" that the ship occupies to the ones of where the "bullets" are, sort of a collision checking function thing.

 

Now should I draw the ship every frame to a brand new clean buffer or "move" them, drawing it to the side and erasing previous stuff?

No not quite. I don't have time right now to really elaborate but you probably want to be going even more basic than that. Ideally you'd want all of the game logic including collision detection to be completely decoupled from having anything to do with drawing at all. You literally just want to be able to say to the thing... draw my scene.

 

For now have a look at the Quadtree datastructure.

[Nuluvius]

Sorry I was watching my little girl's Christmas play...

 

I think that these links do a good job of explaining the kind of overall architecture and considerations that you probably want to be aiming for:

• Game Programming Patterns
  • Sequencing Patterns
    • Double Buffer (this is good because it delves into buffering as @M.Yurizaki mentioned earlier)
    • Game Loop
    • Update Method
• Tips for writing the main game loop?
• Understanding the Game Main Loop

Perhaps do some more general research around the subjects of game based architecture and design patterns. Also, since you are using C# then you might like to consider the Task Parallel Library (TPL), the Task-based Asynchronous Pattern (TAP) and async await.