I'm developing a game with zombie running around in a swamp. I want AIs to have functionality like "chase this target" or "run away". A major stumbling block is pathfinding. Is there a good pathfinding/AI engine in XNA, or should I roll my own?
Does anyone have any experience with this: http://www.codeplex.com/simpleAI?
you may want to look for A-Star algorithms... here is an article that talks about it in the context of a winform, but mentions XNA.
Roll your own! Seriously.
I take it you're making this game as much for the enjoyment of coding, as you are hoping for fame and riches? Pathfinding is one of the staples of AI, and is a well studied and documented topic. It is an excellent introduction to a field you'll need knowledge of in future game endeavours.
The A* Algorithm (as mentioned by others) is the standard solution to this problem - but try other approaches: line-of-sight, scripted movement, flocking... often you can derive interesting behaviour from combining a few techniques.
For a book on the subject, try AI For Game Developers - not the best in the field, but certainly an accessible introduction for the lay-coder.
Have fun mucking about with the zombies!
http://xnapathfindinglib.codeplex.com/
http://swampthingtom.blogspot.com/2007/07/pathfinding-sample-using.html
To everyone that's suggesting A*: you generally wouldn't put vanilla A* into a game. There are a lot of improvements and extensions for A* including (but not limited to) IDA* and transposition tables, that improve performance with A*-based search.
You might want to use a library to get you started but you may ultimately benefit more from your own custom implementation, using your own data types native to your app, instead of having to marshall data back and forth. But you'll need to profile to be sure.
The XNA Creators club has samples for Chase and Evade and Flocking.
I've just started down the path, but they seem to have some good resources on the creators.xna site.
I'll be using some pathfinding logic in my game, the A* Algorithm seems to be the winner for me.
Related
Pako Game
Hi there, I am just starting game development. Specifically with Unity, Android Studio, and C#. Me and my group planned to make a game for our thesis. The problem is that, our professors want us to make a 3D game if possible. Our proposed game is something like Dr.Driving a car simulation where it involves safety signs, road signs and their regulation. Wherein it should look like in the picture(the pako game)
And my question is that, is it easy to make a 3D game for someone newbie like me? Is there any way where I can just import package assets or API? so that I won't spend much more time in designing the environments and even the car?
Your reply will be appreciated. Thank you very much :)
credits to the picture: Pako Game
Spent some time learning the interface, Unity3D is a game engine and as any other game engine, is just a toolbox that let you do things in multiple ways: https://unity3d.com/fr/learn/tutorials/topics/interface-essentials/interface-overview
Forget about your project and spent some time discovering Unity SDK, make a simple pong or tetris or space invader just to get a habit of how Unity forces you to do things it's way (quite different than common OOP)
Discover the Asset Store to find packages that could help you, at least for the visual and the 3C of a game (Character, Camera, Control)
Then and until then, you can be able to sit down and implement your custom game logic. Good Luck.
is it easy to make a 3D game for someone newbie like me?
There are a lot of flavors of newbie. You will need to:
Have or gain some mastery over the Unity interface.
Have or gain some mastery over programming (I'd say in C#).
Have or gain some mastery over Blender* (or rely on 3rd party assets)
Have or gain some mastery over Audacity* (or rely on 3rd party assets)
Have or gain some mastery over story-telling, project management, etc...
So perhaps the easy answer is, "No."? Ultimately, what is easy for one is not easy for another. Easy or not, there will be a lot of work involved, if you plan to create anything worthwhile. That's how it "works".
Is there any way where I can just import package assets or API? so that I won't spend much more time in designing the environments and even the car?
As mentioned, the Asset Store can help you get quickly from A to B or even X, Y or Z. There are assets that are basically complete mini-games, ready to be branded and rolled-out, and there are assets that are just a model or pack of sound-effects. And of course, everything in-between.
In your case, it sounds like you might also need to have or gain some mastery with a modeling tool, such as Blender. It might be your easiest way to get the specific assets you need in terms of the safety signs, but then again, if you are using generic stop and yield type signs the chances are the assets can be found in either the Asset Store, or a 3rd party site like a Blender model site.
*Note: I mention Audacity and Blender because they are free to use, but of course you can use whatever software you like to create your audio and graphical assets.
For those who find the learning curve of Unity too steep for their time or their project, perhaps something like Game Builder would be a better starting-point.
Does anybody know of a website where they have a listing of interesting projects that one can do to gradually ramp up your skills, and stuff that is actually interesting. This could be language agnostic or language specific in which case I am looking for C#. A great example of this diveintopython
Project Euler.
Project Euler is good, but very mathematical - you'll spend as much time on the maths as on the programming. Definitely spend some time working on those questions, but once you reach your mathematical limit (I reached it fairly quickly, and I thought I was good at maths!) I'd recommend working on some simple games. If you still want a listing, here's one:
Text-based adventure
Tic-tac-toe
Tetris
Pacman
Breakout
Mario
Half-life
Project Euler is a popular choice.
I also like CodingBat (has sections for Java and Python, but you can take the problems and use whatever language you like). Its problems are less like puzzles and more like basic programming concept practice.
Well, interesting depends on where your interests lie. diveintopython is more of a advanced book than a list of interesting projects that one can do.
If you like math, Project Euler is popular. But if you don't, like me, just look for a problem that you can solve, a tool that you could use personally. All practice can help ramp up your skills, doesn't matter what projects you work on.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I am thinking of making a simple game engine for my course final year project. I want it to be modular and expandable so that I can add new parts if I have time. For example I would make a graphics engine that would be completely independent of the other systems, once that was finished I could add a physics engine etc.
I would also want to make a tool set to go with this engine. For the tools I would like to use C# but I am not sure about the libraries. My question is, if I want a C# GUI program, can I reference a library written in C++? Also would there be any performance problems etc. if I made some of the libraries in C# but wanted to use them from a C++ game.
I would like to avoid C++ as much as possible, my experiences have shown that development time can be a lot higher for a project over that of using C# or Java etc. My graphics development would be in OpenGL, this is all I have been taught. We have only done this in C++ but I have seen that projects such as SharpGL allow for the development with C#. Is there any performance issues with this. I am not looking for a blindingly fast, top graphics game. It will most likely be something simple to show my engine working. My engine probably won't be that great either as I only have a year and am working on my own.
Any advice on this would be appreciated. I am still really in the planning stages so it wouldn't be too much work to completely change what I want to do. I would just like to preempt any major problems I might have.
Thanks
If you can pull this off even under a relaxed set of goals, you're set for a great project. First, you need to get a grasp of scope:
How long do you have to work on the project?
How many people are working on the project?
If you can only create one "piece of the pie" on your own, which one would you pick? Use this to establish a working plan to make sure if you don't get as far as you'd like, you still have enough to make the work show as a great project.
A game engine is a big development task. A game engine with a toolchain is an enormous development task. In a lot of ways, choosing a smaller but more challenging task is preferable because it shows higher-level thinking about problem solving, which is greatly preferred by academics - double that if you are CS and not [Area of] Engineering. Since you are working in managed languages, things you may want to consider are:
Expressing gameplay logic (rules of the game) in a clean manner so as to provide an efficient and reliable path from designer->developer->tester. If you want, this could absolutely include the manner in which you describe the rules (Custom editor? Code API? DSL?)
Game AI has no shortage of extremely challenging problems.
Physics and graphics are interesting and I believe managed languages will eventually be used in these areas, but you may find yourself a bit more limited in your ability to solve these problems. If I were going to work in this area now, I would be trying to answer: "If I could use a managed language for writing [graphics|physics] code without hurting performance, what kinds of [language|runtime] features make the most difference in improving the expressiveness, correctness, maintainability, and reliability of the resulting programs." This goes way past simply having garbage collection and pointer safety.
You should look into XNA. It performs quite well, and from what I've heard, is quite easy to work with.
About referencing C++ code from C#: It's perfectly doable, though it will take some effort from your side to get it right. C++/CLI can work as an intermediate wrapper or you can use P/Invoke. Just remember that C++ is unmanaged and that you will need to do some manual garbage collection, which can be somewhat icky in a managed environment like .Net. Perfomance in the C++ -> C# bridge is okayish, but I'm unsure how it will perform if you need do 100.000 calls to a math-library each second. I guess a small test would be good.. I'll see if I get time to do this later today, though I somewhat doubt it :)
When creating a graphics engine (I'll only really speak about graphics as that is my area of expertise), these are a few of the choices you need to make EARLY in the project:
1) Is it an indoor and/or outdoor engine?
2) What sort of visibility system are you going to use?
3) Forward or deferred renderer?
4) How will you have animation hierarchies?
5) Dynamic or static lighting?
6) How are you going to handle transparency?
7) How will you handle a 2D overlay?
8) What mesh formats will you use? Roll your own?
Bear in mind you need a GOOD solid vector/matrix library and preferably a full maths library that will help with things from eulers to quaternions to axis-aligned bounding boxes.
Do a lot of research as well. Try to find out what the potential problems you are going to face are. Remember things like changing a texture or a shader can have HUGE impacts on your pipelining. You need to minimise these as much as possible.
Bear in mind that getting a rotating bump mapped mesh on the screen is simple by comparison to getting an engine running. Don't let this put you off. It should be no problem to write a fairly simple game rendering engine in a matter of months :)
Also ... find communities specific to this area. You will get a lot of good (though non-OpenGL-centric) information off DirectXDev. There is a fair bit of general game development algorithm information available at GDAlgorithms. There is also an OpenGL specific mailing list here.
Its worth noting that DirectXDev and GDAlgorithms, at least (I don't know so much on the GL mailing list) are populated by some VERY experienced 3D engine and game developers. Don't post up lots of "beginner" questions as this does tend to breed contempt among the members. Though the odd query or 2 at whatever level (beginner to advanced) will get amazing answers.
Good luck! I wish I'd had the chance to do this at University. I might not have gone off and joined the games industry and enjoyed an extra year of sleeping late ;) hehehe
Why do you need any C++ code?
There are already several wrapper libraries exposing OpenGL or DirectX to .NET, such as SlimDX (which, as the name implies, is a much thinner, more light-weight wrapper than something like XNA)
If you're more comfortable with C#, there's no reason why you couldn't write your entire game in that.
Performance generally won't be a problem. In most cases, the performance of C# code is comparable to C++. Sometimes it's faster, sometimes it's slower. But there are few cases where C# isn't fast enough. (However, there is a significant performance cost to interfacing between native and .NET code -- so doing that too often will hurt performance -- so the trick is, if you use native code at all, to have sufficiently big native operations, so the jump to/from .NET isn't done too often)
Apart from that, a word of advice: Don't bother writing an "engine".
You'll be wasting your time producing a big monolithic chunk of code which, ultimately, doesn't work, because it was never tested against the requirements of an actual game, only what you thought your future game would need.
If you want to experiment with game development, make a game. And then, by all means, refactor it and clean it up and try to extract reusable parts of the code. But if the code hasn't already been used in a game, you won't be able to use it to build a game in the future either.
The engines used in commercial games are just this, code extracted from previous games, code which has been tested, and which works.
By contrast, hobbyist engines pretty much always end up taking 2+ years of the developer's time, without ever offering anything usable.
The whole concept of a "game engine" is flawed. In every other field of software development, you'd frown at the idea of one vaguely-defined component doing basically "everything I need to make my product". You'd be especially suspicious of the idea that it is a separate entity that can be developed separate from the actual product it's supposed to support.
Only in game development, which is by and large stuck in 80's methodologies, is it a common approach. Even though it doesn't actually work.
If this is a school project, I'm sure whoever is supposed to grade it will appreciate it if you apply common good software practices to the field. Just because many newcomers to game development don't do that (and prefer to stick to some kind of myth about "engines"), there's no reason why you shouldn't do better.
Make sure your scope is feasible.
As a teenager I went through the build-my-own-engine phase, a few years later I realized I would have gotten a whole lot more done if I had just used pygame and pyopengl and not wasted the effort.
Check out the forums at gamedev.net.
Sounds to me like you have a pretty good plan for your project. (I get your point about XNA in your comment to #Meeh)
You can interop with C++ via P/Invoke directly or COM, you could also I guess come up with some SOA way of doing it, but to be honest as yucky as this sounds I would be inclined to target COM as your API lever of choice...why? because then you open up your API to a lot of common client language's not just C# and VB.NET you will also get Delphi, VBA, Powerbuilder etc.
Performance should not be a problem as the API entry points are just to kick of the work and transport data structures, the real work is done in your library in native code, so don't worry too much about the perf. ATL will be your friend with creating COM Classes that provide entry to your Library.
Whilst it's certainly do-able to bridge between C++ and C# (Via managed C++ is a good way to go if the interface is complex, P/Invoke for a very simple one), for tool<->engine communication I might suggest instead a network based interface. This is ideal for a high-ish level interface, such as you might want for a level editor/model viewer or such. An actual object modeller is not such a good target. What tools do you envision?
If you do it this way you gain the ability to connect to remote instances of the engine, or multiple instances, or even instances running on different hardware platforms. It'll also teach you a bit about sockets if you don't know them already.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I want to design a 2D game idea with C#/XNA. Between school, project inexperience, limited resources, and other things that may cause me to bail on the project I am going to try to plan it out before I jump in:
What are some key aspects you've noticed in a successful personal project?
How did you (successfully) draw revenue the project (besides asking for donations)?
(Note: this is not the main purpose of my project but would be nice!)
How do you plan non-programming aspects like window layouts (UI), flow of game, and look and feel?
How do you bring an abstract idea of a game and making into a real product. What tools do you use in your sketching and planning?
With limited resources (artistic talent and money), how do I create some of the art resources I need (besides stock art)? Or should I not worry about that until I have a finished product?
Finally, how do you break barriers in your code (may it be knowledge, time, or perseverance)?
What are some key aspects you've noticed in a successful personal project?
I suppose this largely depends on your definition of success. I consider a game project successful if:
It's fun. Enough that I want to play it after I've finished.
I learn something in the process of making it.
I actually complete the project, where complete is defined as having art, audio, and any other assets adequate for the style of game that I'm making.
It works under 'field conditions', rather than simply on my own machine/hardware configuration.
In my case, every project that I've considered successful has been one that I've done some serious planning on and committed to seeing through to completion. That's the biggest step for me to get past. A casual project that is the product of a bored weekend usually won't get finished.
How did you (successfully) draw revenue the project (besides asking for donations)? (Note: this is not the main purpose of my project but would be nice!)
Heh. Haven't managed this yet. But then, that hasn't been a concern of mine enough to do the work required to support it. Someone already mentioned the potential revenue from XBLA for XNA projects, which is a very easy avenue to success if your project is the sort of thing that translates well to the console. I've looked into it, but it isn't really appropriate for my projects so far.
How do you plan non-programming aspects like window layouts (UI), flow of game, and look and feel?
Pen. And paper. I draw a lot of screenshots as guides and I'll usually have some kind of artistic theme in mind to go along with the gameplay. Rapid prototypes help here too; everything from making mockups of menus and various screens in a drawing program to making some simple interactive stuff in a throwaway project.
Write everything down. I take lots of notes and I've been known to have a laptop with notepad open on it sitting next to my development machine, to save me the trouble of alt-tabbing away from my code to type a quick note on what I'm doing. Some great ideas come out of the process of trying to make other things work and if you don't write it down, it didn't happen.
How do you bring an abstract idea of a game and making into a real product. What tools do you use in your sketching and planning?
Work iteratively as much as possible. I hate to sound cliche, but the whole agile model works really well for games. Start with that core 'fun' idea you have that inspired you to make a game in the first place and get that working in code. Maybe it's a single mechanic that you want to build puzzles/levels around or maybe it's more of a look/feel that you can capture in a single environment/level/whatever. Either way, if you can get a single example of it working right, it becomes a good check on whether the idea is actually viable and will likely give you some ideas of the different ways it can be implemented. That might seem kind of vague, but more specific advice would depend on any number of other factors (your choice of genre, audience, the specific ideas you have in mind, etc.).
With limited resources (artistic talent and money), how do I create some of the art resources I need (besides stock art)? Or should I not worry about that until I have a finished product?
Peter Molyneux of Lionhead has said that he used to prototype all of his games with ascii art. If they were fun with that limited level of graphics, then they were worth continuing. While you might not be able to get that simple with some genres (and an ascii 3d shooter might be novel for it's own sake...), certainly worrying about finished art, audio, or other assets is something that can be saved for much later. In the end, if the game is fun to play, then getting an artist willing to work with you becomes a lot more trivial. I have, on many occasions, used copyrighted assets during my prototyping phase when I just couldn't stand to look at my own art any longer. Just be sure that you have anything like that replaced before you start distributing your project...
Finally, how do you break barriers in your code (may it be knowledge, time, or perseverance)?
Not sure exactly what you're thinking about here, but breaking barriers is what writing code is all about really. You're finding creative solutions to interesting problems. The web is a great resource for general knowledge, but in the end, it's your own time and perseverance that will create something interesting.
Best of luck.
What are some key aspects you've noticed in a successful personal project?
Don't worry about how it will turn out
Do it for fun
Don't plan it
Start small, don't think big
Actually code instead of procrastinating on so or other similar sites
If you want somebody else to use this game, make it non personal. Get somebody else who you can give demos to and get feedback from. Make the game very very simple. Build that first before moving onto something very simple. Then go for simple!
not sure :)
Plan with pen and paper sketches for window layouts and game flow. For look and feel, browse the web for slick looking sites you can take inspiration from.
Use notepad, and write the shortest list of things that need doing to make the simplest working demo. Only work on the things you wrote down otherwise you can get carried away on some detail and end up not producing anything useful.
Art is an important part of a game, and you can't have a finished product without it. How about searching the web for a collaborator who'd be interested in doing it for you.
If your stuck with something in your code, ask for help on StackOverflow! :)
Key aspects: Primarily, something that you are excited about. Make a game that REALLY gets you going, and you'll be motivated by your desire to share the finished product with others -- your end product's quality will probably be improved by your passion, as well.
Profitability: Well, since this is XNA and all, if you release a version on Xbox Live, you will earn 70% of the sales revenue that your game earns. Games can be priced for 200, 400, or 800 points (roughly $2.50-$10).
UI/Usability: For this, I typically go through a lot of playability testing...booting it up, seeing how things "feel," then tweaking things if they just don't feel right. I came across a lot of things that I never really thought about before (fade-ins/fade-outs for menus, repeat rates for keys, and so forth), and play-testing is one of the more effective ways that I've been able to identify issues like that. If you've got friends, you can ask them to give you feedback as well.
Planning Tools: Truthfully, I just make a list of the things that I want to include in the overall game concept, then slowly get more granular as I iron out more and more of the fine details. Certain ideas inevitably change after playtesting may reveal them to not be as fun as you had imagined they would be, of course. I haven't ever seen a huge need for any formal tools for this process, though, but I will give the disclaimer that all of my projects have been fairly small in scope and have not been professional-sized undertakings or anything.
Art: This may not always be an option for you, but I have a few friends online that are gifted with art skills -- I solicited interest, and got some volunteers. I presented the option to earn a cut of whatever royalties may come in, but most of them were happy with an attribution in the credits and a chance to see their work in a game that's playable by people all over the world. Regarding small things (icons, etc), stock/royalty-free art can do the job in certain cases, too, but I wouldn't recommend relying on it.
Breaking Barriers: Not sure what's quite meant by this question, but generally speaking if I've come up against some sort of unforeseen issue (technical/implementation challenge,
gameplay-related, or what-have-you), I'm able to either solve the problem or come up with a suitable work-around if I put my mind to it for long enough. Did you mean something else by this?
Some great thoughts given in these articles:
http://www.flatredball.com/frb/docs/index.php?title=Tips_for_Completing_an_Independent_Project
http://makeitbigingames.com/2006/06/five-realistic-steps-to-starting-a-game-development-company/
http://makeitbigingames.com/2006/02/five-foundational-steps-to-surviving-as-a-game-developer/
First of all - I know universities don't tend to teach this but you really must do it... get source control going. I would suggest installing TortoiseSvn from here: http://tortoisesvn.net/downloads
With TortoiseSvn (a subversion client) - you can create a repository on your USB Flash Drive and carry it around with you, so you always have a copy of your project files. More importantly you can have more confidence when you make changes - because it keeps a history of the changes you've made. So if you break something, you can revert to the most up to date version on your usb flash drive... or even an earlier version if you wish. It also provides ways of showing differences between file revisions, all from the explorer shell extension.
For a personal project the key thing is to keep motivated. You keep motivated by setting yourself attainable tasks. Aim for something attainable. Always make sure you can build your project. Concentrate on adding new functionality while keeping the old stuff still working rather than building up huge nicely designed framework that might end up going no where. If you write your code well, you can refactor and abstract later after you figured out what game it is you actually want to build.
I would advocate a todo list of some kind... something like the spreadsheet found here on Joels site: http://www.joelonsoftware.com/articles/fog0000000245.html
If you want to get fancy, I would suggest something like Trac: http://trac.edgewall.org/
Trac is a wiki, to-do / bug list and repository viewer all in one. If you get someone else working with you on a project, collaboration with source control and a shared wiki becomes more useful. It's also good to work with others... you can keep each other motivated.
The Wolf fire blog recently had some interesting design ideas and cited serval sources here: http://blog.wolfire.com/2009/02/design-principles-from-tufte/
As for getting money, others have already covered the community games thing.
Art assets - there are a few places to find these. Scout the forums at www.gamedev.net. Def look at this blog here for some excellent art (and game design ideas) http://lostgarden.com/
Others have suggested keeping tools simple - I would agree. The simplier and more accessible things are when it comes to project planning, prototyping and design - the more likely you are to use them. As long as you can communicate with yourself when you revisit something... or other people when collaborating, it's a good tool. Set yourself attainable goals, and get on with it :-)
What are some key aspects you've noticed in a successful personal project? Focus on something that actually works.
How did you (successfully) draw revenue the project (besides asking for donations)? Not directly. However, skills get you a job. Build skills.
How do you plan non-programming aspects like window layouts (UI), flow of game, and look and feel?
Build the inside -- the core data model first. If the data model works, everything else is far simpler.
Build unit tests for the model to be absolutely sure it always works.
Work out "flow" and other control issues based on that model.
Build the GUI later, once you have a solid foundation.
How do you bring an abstract idea of a game and making into a real product? What tools do you use in your sketching and planning?
I do the following.
I use Argo UML for technical UML diagrams.
I write documents with my end-state in mind. What the API will be like. How it will work. As part of writing the documents, I clarify my thinking.
I write code in pieces, with unit tests, and refactor ruthlessly.
With limited resources (artistic talent and money), how do I create some of the art resources I need (besides stock art)? Or should I not worry about that until I have a finished product?
Find an artist who wants to help.
Finally, how do you break barriers in your code (may it be knowledge, time, or perseverance)?
Build the inside -- the core data model first.
Spike elements of the technology separately from the main development. Build separate proofs of concept for each new technology. Do not try to integrate unknown technology into the final product. (Many of my customers try this and it doesn't work.)
Having had an experience with game development in my teenage years what I can suggest is the following:
Make sure you have the story ready, or at least the basic points before you start implementing. Also make sure that you do not change the genre of the game while in dev stage. (yeah, I know, this is stupid, but could happen ;-) )
We actually drew some revenue when we managed to sell the game to a software house, however because we had already spent too much in the dev process, we just broke even (i.e. to little profit). So be careful what you spend beforehand
From what you said, you're still in school, so take advantage of that. There will surely be folk out there with artistic talent, most probably friends of yours. Make a team. That's what we did and it was all the way back in 1993! At that time it was even harder. We introduced our talented friends to 3D-Studio (v3 back then) and some even to computers in general, and believe me, before you knew it they were making brilliant art out of it!
Use pen and paper to create the story boards (even better with the friends mentioned above. Decide on the development approach. I.e. what libraries will you use etc. Read a lot about game dev. Make a plan of the project. Give it your best ;-)
Unlike us back then, you have the web to help you. For whatever problems you have with your code it is easy to look it up. StackOverflow didn't exist back then!
And of course make sure you have fun in the process otherwise it will eat you alive!
What are some key aspects you've
noticed in a successful personal
project?
Just do it!
Going to create a small game with OpenGL as a side project. Going to be a top down shooter with emphasis on large numbers of enemies (the more the merrier)
Thinking about having the resolution max out at 800x600 (for an old school feel)
What language would you recommend, is C# capable of handling the number of entities I want on screen (60-100) or should I try out C or C++ or even some other language.
Do you have any other suggestions when going for a project like this, special documentation you recommend etc.
C# is easily capable of handling a few hundred objects at once. The real speed issues come from rendering, which will not be in C# space, and possibly any computation you want to be done for each object, such as physics. Ideally you'd be using a library such as Box2D or Chipmunk for that anyway, making C# speed a non-issue there as well.
I'd personally be willing to write a game such as this in even-higher level languages than C#. C# should easily suffice.
On the scripting languages tip, consider the excellent Pygame in python:
http://www.pygame.org/news.html
Or the newer LÖVE in Lua
http://love2d.org/
For a top-down shooter both are probably excellent choices.
Have you considered Haskell, D, or ADA?
C# will definitely be able to handle a paltry 60-100 OpenGL-rendered entities on any reasonable hardware.
Generally, for a project of this scope I would recommend using whatever language you want to learn next.
Your project scope isn't huge, but is meaty enough that it would probably stretch your knowledge of the language you choose a bit. So choose one you want to get better in.
I've only ever dabbled with it but LWJGL will facilitate a Java version. All of the in-house games at puppygames.net are done in Java with LWJGL, for instance, and curiously they too are top-down or side-on blaster style games.