Simulation/Strategy where do I start?Monkey General Forums/Monkey Discussion/Simulation/Strategy where do I start?
| Hello all,|
I'm a newcomer to Monkey/BlitzBasic but I've worked as a developer for several years (primarily client/server development for Windows environment). That, unfortunately, means I feel like a complete newcomer when it comes to games programming :).
Now, I've been playing around with the demo version of monkey along with some of the tutorials until yesterday when I decided to purchase the monkey-package and I'm very excited to get started with an idea I have for a game.
Now, I will be taking small steps, and my "grand" ideas won't be my first projects, but I would like to build up towards being able to create a more strategy-like game, and my "niche" of games would be what you might find in the lower price ranges in the various appstores, smaller strategy and time management games.. some with RTS like functionality.
However, as a complete newcomer to games programming, I'm at a bit of a loss as to where to start. Most of the tutorials around here are for shooters and platform games, but as you understand I've got something else in mind.
Where should I start? Are there any frameworks that would be suitable for my type of needs? Much of my gameplay will be point and click with some spritemovements around background image (i.e. not necessarily scrolling backgrounds)..
Any pointers towards tutorials and frameworks for these types of games would be much appreciated!
| Personally, I would start with your data types and classes, and once you have those working properly move on to the interface. |
| You can still use the basic concepts from games like space shooters or platformers.|
Just make a kind of class hierarchy and use that as a reference point. E.g:
YourGame - Scenes -- Entities --- ...
The entities then could have components you just plug in for the logic. I think especially in an RTS game it will pay if you don't hardcode the logic. Here is what I mean.
Class Entity Field strategy:Strategy Method Update:Void() strategy.Update() End End Class Strategy Abstract Field pointer:Entity Method Update:Void() End Class Aggressive Extends Strategy Method Update:Void() ' The aggressive strategy End End Class Defensive Extends Strategy Method Update:Void() ' The defensive strategy End End
Diddy is a general framework that is suitable for any kind of game. At least you can borrow some code from it :O
| Thank you both for your suggestions. I'm used to mapping out a class-structure first (my main pattern from desktop and web applications is MVC), but I felt a bit overwhelmed realizing just what a different world game programming is :).|
I will be taking a look at Diddy for sure, and I'll delve deeper into any open sourced monkey-projects I can find to get a feel for basic stuff such as scenes etc. I'm also reading the book "Monkey Game Development" by one of the forum members here.
Thanks again to both of you :)
| First of all Welcome to Monkey.|
It's hard to really tell what your first move is because you already have an experienced understanding of programming so if I were in your shoes I would break my idea down into segments and then write small projects to test out those parts.
Your talking about rts, so my first project might be having a unit on screen and then being able to click on it and tell it to move some where else, using some path finding, like A* or line of sight.
I might then add to this something to shoot, like some enemy units, this will let you sort out collisions, and give you the chance to play with some AI, having your enemy move around and react to your player unit.
finally I would mess with some UI stuff, play around with displaying some heads up display items you might get in an rts, mini maps, unit's etc.
I think if you mess with these little projects first, to get your feet wet, you will be able to put it all together into a more robust game when your ready to do your main project.
| Thank you Taiphoz, you described my predicament very well. The most basic tutorials feel a bit too basic because of my programming background, so it's difficult to know where to "jump in".. right now I'm doing the stuff in the book I mentioned, but it's mostly shooters which I'm not that interested in doing, but I feel I'm getting an idea of how things work in a game-development situation.|
I was planning on breaking down my ideas into smaller project just like you suggested. For example, I have an idea for a minigame between levels in my strategy game, and I figured it would be a nice place to start, but things such as pathfinding etc will be essential later on, so I will probably add your suggestion to my list of things to do :).
| welcome to monkeycoder.|
I made my first game a tower defense. that helped a lot and kept the project "definable" meaning i knew what the game was suppose to end up being, which cuts down on design decisions.
another idea for a first game would be something like asteroids or pacman, again something where you know already what it is suppose to look like.
| MVC can apply to a game also. Your game is the model and what the player sees is the view. He can click to tell the game to give a unit orders, or to change the view. When in-game time passes, the game is informed and updates itself, with all units moving or acting appropriately. In the most simplistic case, the view will always show the current state of the game. In this case writing an RTS won't be so different from writing a boardgame like Chess.|
Complications can arise when you want to get a bit fancy with graphics. For example say the game atomically processes a shell hit and several troops die, but you want to show that graphically over a period of time. You can get away with a certain amount of letting the view look after this kind of thing, but that gets messy as it gets more complex. But modelling this extraneous stuff in your game is also messy. In short, game programs always get messy, especially as game design is usually done simultaneously with development! It's very important not to overcomplicate things or try to find the perfect, ever-expansible design.
| As for game ideas to cut your teeth, I tend to make a shooter cos its the kind of game I enjoy, currently working one both because I had it planned, but also to get me used to the framework I am using.|
Like Adam said, pick something that you can really follow like a step by step, pacman is perfect, very few moving parts if you will, 1 ghosts follows you, 1 runs away from you and another moves at random, and you pick up dots, so you cant really get lost in the mechanics, or suffer from feature creep.
good luck in what ever you pick.
| Since you are new to games programming, I suggest you try to recreate the classics first:|
* Space Invaders
* Platformer (eg Super Mario Clone)
(and maybe in that order too)
| Well, if he wants to do strategy games he wants to do strategy games. I would agree that he should do one simple arcade-type game such as those suggested in order to get the hang of animation, as that is a subject that may not be familiar to non-games programmers. After that he can veer more in the direction of the game types he likes.|
Pacman might be a good practice game for someone who wants to do an RTS.
| I have to say I'm (positively) overwhelmed by all the kind advice and helpful discussion. Thank you everyone for chipping in. |
As part of the book I mentioned above, I'm about to dive into writing the game in chapter 7, "At the docks", which is a small Sokoban clone. From reading through the chapter first, I know that it will introduce me to level handling, sprite maps and collision handling.
Now, throughout this book, I've been using a framework created by the author called the fantomEngine. It has given me a free ride regarding some core stuff and I'm wondering if it's a mistake to use a framework this early - I might miss out on "understanding" some of the basics, and I might also make me a bit dependent on it for future development as it might be "the only thing I'm used to".
Any thoughts on the fantomEngine? How many here use it?