Well my old "supersonic game engine" turned into a Computer Programming class project, and we are basically going to make a game; I'm in charge of programming the engine... and I'm also in charge of the entire project as project manager. My class chose me as project manager because 1) I was the one that suggested the original idea of even making a game this semester (before that decision, everyone was going to have to program their project in Python, and not everybody in the class liked Python!) and 2) I was assumed to have the most knowledge of being a project manager. Well for the past two or three months already its been quite a fun adventure, which is why I'm here to write about it now. I don't have any professional experience as a project manager, but I've tried to do my best, and it is true that I have read the post-mortems of project managers, so I wasn't entirely clueless!
Thus far, the project has gone considerably well.. Its not every day a group of 7 high school students pull off a professional quality game in 4 months, so that's not what we're aiming for. We did challenge ourselves to making a 3D game, so three team members are dedicated to 3D modeling (and those three have turned out some models that blew my initial expectations) As the project got started, we only knew we wanted to do kind of a spin off of Beowulf, so one person worked on writing a kind of storyline, dialog scripts and stuff like that.
At the beginning, from week 1, we had really no clue of where the game was headed. We had no ideas for a combat system, we had no ideas for what the game would really look like which made it hard at first. For team communication outside of class, and also for record keeping and kind of a history, we used a wiki over at Wikispaces and this is where most of the team has been able to effectively communicate their ideas and overall, we have been able to pull something together. The wiki actually started on a school website, and our teacher had set it up for us, but that wiki was limited, and it was old; so we switched to Wikispaces.
As ideas started to develop, the busiest team member was the story writer. Our story writer was perfect for the job, because his goal was to become an English teacher after he finished school, and he has written so many things in his time. The 3D modelers and artists didn't have very much to do at first, but that was okay as they started out learning the ins and outs of Blender One of the guys on the team was originally going to help me out with programming, although he would be more focused on scripting and stuff. Early on, however, he decided he would rather work on level designs. As if an engineer, he got right to work on drawing levels, the GUI and the menus on engineer's graphing paper, and along with that he also got started on designing controls and working on the mechanics of the game. Me and the only other programmer, similar to everyone but the story writer, didn't have much to do as the project started off, so I kept working on the engine I had previously started, hoping to design it with a focus on this game rather than the reusable engine I had previously dreamed of. The other programmer was a bit new to Python so he continued working on learning Python, although, a quick learner he was, he was sitting in the back with me and me and him decided he would do best working on the GUI.
One of the things that me and my teacher found most effective so far for getting the other team members to work is giving out a prize each week to the student who has contributed the most (whether it be some really nice models, lots of constructive wiki posts, or in general, a lot of quality work finished). As project manager, I have felt that it is my responsibility to keep the team on task, and present a goal for them to try to achieve (because as procrastinators, we all know that none of us will do anything without a goal in mind!). A tool I found to be somewhat effective is something called a Gantt Chart. I have never been too much of a visual person, but a Gantt Chart is perfect because it is a one stop reference for deadlines, a timeline, and it helps me see what tasks are more important, based on what other things depend on those (for example, the first stages of modeling and engine programming are very important in order to get to the first testing phase). Another useful tool I have used is a mind map, and using XMind I was able to create a mind map with a printable outline. I found that this was really only useful to me and the GUI programmer because no one else really has any mandatory requirement to care about the design behind the engine.
If I had to say anything to someone else that wants to be a project manager, I would say two things. 1) ask me in a few years after I get professional experience in this job, and 2) make sure your team has a clear goal of what you want to achieve!
Friday, April 29, 2011
Sunday, February 20, 2011
A beginner's philosophy in fixing problems in Linux
I am quite sorry I haven't posted in two weeks, but that probably doesn't matter since no one reads this. I've been a little bit preoccupied by school, although this weekend I was actually more occupied by my car. I did my first oil change and it took a few hours because I didn't know how to do it! Next up is a brake job.
Anyways, I was having some problems with CEGUI... and I fixed them. Do you want to know how? I upgraded to a newer version of OGRE and CEGUI... in the process I also reinstalled, but I don't truly know if it was the upgrade or the re-installation that fixed the problem. This reminds me of my first days in linux though. Back before Ubuntu 10.04 was out, in late 2009, I installed Ubuntu 8.04 thinking it would be better for me as a beginner (seeing as it was the "LTS" which I understood to mean perfect). I don't exactly remember what problems I was having, but upgrading to Ubuntu 9.10 fixed them. Later, (and again I don't remember the specifics), I had experienced some problem with my graphics card in Ubuntu; needless to say, updating the driver fixed it for me. I could probably name a hundred other times upgrading software has fixed a problem for me (or downgrading from 64-bit to 32-bit), but for the sake of your time I won't.
As far as stuff in OGRE has been progressing, I promised screenshots so here is one. Overall, my progress has been getting stuff to work and creating an overall framework. This screenshot is something I put together while testing animation, and some of the entities are left over from when I was running the application for the first time.
Anyways, I was having some problems with CEGUI... and I fixed them. Do you want to know how? I upgraded to a newer version of OGRE and CEGUI... in the process I also reinstalled, but I don't truly know if it was the upgrade or the re-installation that fixed the problem. This reminds me of my first days in linux though. Back before Ubuntu 10.04 was out, in late 2009, I installed Ubuntu 8.04 thinking it would be better for me as a beginner (seeing as it was the "LTS" which I understood to mean perfect). I don't exactly remember what problems I was having, but upgrading to Ubuntu 9.10 fixed them. Later, (and again I don't remember the specifics), I had experienced some problem with my graphics card in Ubuntu; needless to say, updating the driver fixed it for me. I could probably name a hundred other times upgrading software has fixed a problem for me (or downgrading from 64-bit to 32-bit), but for the sake of your time I won't.
As far as stuff in OGRE has been progressing, I promised screenshots so here is one. Overall, my progress has been getting stuff to work and creating an overall framework. This screenshot is something I put together while testing animation, and some of the entities are left over from when I was running the application for the first time.
Sunday, February 6, 2011
The Evolution of the Supersonic Game Engine
This week has been incredible; it is Super Bowl Sunday today of course (Go Packers!) and cold weather has hit hard on several places throughout the States, notably Chicago's blizzard, and for some reason, Dallas has been big on the news.. I think I heard somewhere that since it snowed in Dallas this week, right before the Super Bowl, it's possible that now Dallas is cursed and might not have the Super Bowl again... Actually I'm not sure of that, I think I head it but I can't give you a source on that so moving on; should be a good game!
Well in Colorado, where I'm from, we've had some nice weather... It was only like -3 degrees (Fahrenheit). Of course a few areas such as Evergreen seem to have experienced temperatures of -20? And I did not get one snow day from Red Rocks! Awesome! The high school I go to did close for Tuesday and Wednesday, so I had a little bit of time to do extra homework then. Due to that, yesterday I had a good 10 hours of coding.
To be exact, that was seven hours of coding and three hours of debugging. I can't get into the habit of testing code as I write it, so I sit down and just code for a few hours without running any of it. I have to admit though, I have discovered I absolutely love Python for one big reason. I remember writing a few things in C++, I spend a long time designing a class (I never liked using UML, I would design it by writing class definitions and comments) and then I would write the class, and test it. The testing process involved practically coding an entire project to test each element, and this is why I don't test while coding. Well in Python, after writing the class, testing it is as simple as opening the command line interpreter, and typing code such as the following:
Well I guess that was biased, but you get the point. I did have a good time debugging. I made myself slightly familiar with pydb, and then I learned of the existence of pdb which served my purposes just as well. Part of the debug process for me though was trying to figure out why the log manager didn't work. I had perfectly working code when I started, and then when I started debugging, I spent about an hour trying to figure out why I kept getting an error message about some kind of threading.
I haven't figured out how to fix the code and make it work, I just commented out all the places I send messages to the log manager. I did make progress with at least an error message to refer to when I tested the project in Ubuntu. I switched to Windows to see if the error happened there and--well I didn't get any kind of error message, I did get a message to the effect of "'python.exe' crashed. Sorry. Checking the internet for solutions........ No solutions; sucks for you! Bye bye loser!"
After commenting the code out, the application wouldn't display anything on the screen for some reason.. Well I was using the Borg pattern and in order to call functions from my framework (which is where I used the Borg pattern) I would do something similar to
I did the variables as such so I could keep track of what variables I was using, but what that did: 1) it would have caused a huge memory leak if there was no garbage collector... Heck it probably still caused a memory leak somehow and 2) OgreFramework.m_pRoot which I stored the OGRE.Root object in was a blank reference; when I asked it to render the scene it threw an exception that I didn't catch. Well I am still able to keep track of variables as such, I just moved all the 'definitions' outside the __init__ function, and when I call the inherited classes __init__ function, I set a flag to see if I had already done so. What I should probably do is instead of calling OgreFramework() everywhere, say framework = OgreFramework() framework.doSomething()
Well I promised screenshots, but right now I don't have anything pretty, just the media that comes with OGRE, like the ogre head, the robot, the ninja, etc. If anyone has read this, and thinks I could possibly benefit from some better design problem (that might fix my problems with the Borg pattern) let me know! This week, I have a framework and state manager that at least works, and I have a pretty good idea of what I will be doing for the rest of the project. Instead of making a "game engine," however, I'll be making a physics demo to 1) submit for some scholarships possible, 2) better my understanding of physics so I can do well in my Calc-based Physics class, and 3) I can get more acquainted with OGRE and Python. I will then convert it into an engine, but I would much rather move the whole thing to C++ if I make an engine.
Well in Colorado, where I'm from, we've had some nice weather... It was only like -3 degrees (Fahrenheit). Of course a few areas such as Evergreen seem to have experienced temperatures of -20? And I did not get one snow day from Red Rocks! Awesome! The high school I go to did close for Tuesday and Wednesday, so I had a little bit of time to do extra homework then. Due to that, yesterday I had a good 10 hours of coding.
To be exact, that was seven hours of coding and three hours of debugging. I can't get into the habit of testing code as I write it, so I sit down and just code for a few hours without running any of it. I have to admit though, I have discovered I absolutely love Python for one big reason. I remember writing a few things in C++, I spend a long time designing a class (I never liked using UML, I would design it by writing class definitions and comments) and then I would write the class, and test it. The testing process involved practically coding an entire project to test each element, and this is why I don't test while coding. Well in Python, after writing the class, testing it is as simple as opening the command line interpreter, and typing code such as the following:
>>> from SampleModule import SampleClass
>>> import OtherThings as ABunchOfCrap
>>> import SuchAsOsOrTimeOrSys as YouProbablyNeedThese
>>> sampleObject = SampleClass (param1, param2)
>>> sampleObject.doSomething (param42)
>>> sampleObject.rootForPackers (theyAreTheBest)
>>> sampleObject.rootForSteelers ()
Traceback (most recent call last):
File "", line 1, in
NameError: name 'steelers' is not defined
>>> Well I guess that was biased, but you get the point. I did have a good time debugging. I made myself slightly familiar with pydb, and then I learned of the existence of pdb which served my purposes just as well. Part of the debug process for me though was trying to figure out why the log manager didn't work. I had perfectly working code when I started, and then when I started debugging, I spent about an hour trying to figure out why I kept getting an error message about some kind of threading.
I haven't figured out how to fix the code and make it work, I just commented out all the places I send messages to the log manager. I did make progress with at least an error message to refer to when I tested the project in Ubuntu. I switched to Windows to see if the error happened there and--well I didn't get any kind of error message, I did get a message to the effect of "'python.exe' crashed. Sorry. Checking the internet for solutions........ No solutions; sucks for you! Bye bye loser!"
After commenting the code out, the application wouldn't display anything on the screen for some reason.. Well I was using the Borg pattern and in order to call functions from my framework (which is where I used the Borg pattern) I would do something similar to
OgreFramework().someFunction (someParams). While working through pydb with the code, I realized that everytime I call OgreFramework().something, it runs OgreFramework.__init__(), and in there, I set every single variable to 0 or False or "" or [] or {} or... well you get the point.I did the variables as such so I could keep track of what variables I was using, but what that did: 1) it would have caused a huge memory leak if there was no garbage collector... Heck it probably still caused a memory leak somehow and 2) OgreFramework.m_pRoot which I stored the OGRE.Root object in was a blank reference; when I asked it to render the scene it threw an exception that I didn't catch. Well I am still able to keep track of variables as such, I just moved all the 'definitions' outside the __init__ function, and when I call the inherited classes __init__ function, I set a flag to see if I had already done so. What I should probably do is instead of calling OgreFramework() everywhere, say framework = OgreFramework() framework.doSomething()
Well I promised screenshots, but right now I don't have anything pretty, just the media that comes with OGRE, like the ogre head, the robot, the ninja, etc. If anyone has read this, and thinks I could possibly benefit from some better design problem (that might fix my problems with the Borg pattern) let me know! This week, I have a framework and state manager that at least works, and I have a pretty good idea of what I will be doing for the rest of the project. Instead of making a "game engine," however, I'll be making a physics demo to 1) submit for some scholarships possible, 2) better my understanding of physics so I can do well in my Calc-based Physics class, and 3) I can get more acquainted with OGRE and Python. I will then convert it into an engine, but I would much rather move the whole thing to C++ if I make an engine.
Friday, January 28, 2011
Supersonic Game Engine Week 3
I guess I can't entirely say this week was productive as far as lines of code produced, but in terms of how much I have designed and learned, this week was one of the most productive in my life. Aside from starting college courses last week (18 credits) I also did a lot of homework over the weekend, and definitely learned a lot there. Oh, by the way, anyone who does not already know: One of the best ways to manage everyday activities, homework included, is something called Remember the Milk. I absolutely love this website and highly recommend it to anyone who is currently living and not scared of computers.
Well, that aside, I would like to update anyone reading this on my progress. This week, I didn't do a whole lot of coding for the Supersonic engine, but I did quite a bit of reading. I have read about quite a few different game frameworks both specifically for OGRE, and unrelated to OGRE at all. Obviously I found those ones related to OGRE quite a bit more interesting and helpful, but I picked up some basic concepts (Singletons and threading) from other articles.
One of the most interesting articles I read was the Advanced OGRE Framework tutorial on OGRE's wiki. It is basically a code listing for a nice framework for OGRE applications, and appears to be quite useful to me. What little coding I have done this week was porting that framework to Python so I could use it myself. That framework includes with it a state manager, but I opted to write my code based off (not copying word for word) a different state manager also found on OGREs wiki. With that, I now have working input!
One thing that will inevitably be essential to the creation of a game engine is a Singleton. For that matter, it has definitely been a little challenging trying to figure out how to make a singleton in Python, because it's not a built in language feature. Luckily, this was made easy by another article I found: (link found on python-ogre wiki) Singleton Metaclass. Okay, I will admit I have not taken the time to look that over and figure it out (and considering it's simplicity, it seems like it might be pretty easy; don't forget: I only started programming with Python a few weeks ago). It sure looks promising though.
My plans from this point forward are still to get some kind of simple game in the works, featuring input, terrain, movement, animation, collision, game states (menu/pause menu) and a level manager. I have never ever used shaders before, and I barely even know what they are, but if I'm up to the challenge in the coming weeks I might even check out shaders and make some kind of weird metallic guy, or I could simply add a body of water; it would be cool to have a shiny rainbow tree though! For this week I'll simply work on animation.
I sure hope I can manage when it comes to the point of creating my own content. Anyone that would like to help me with that is welcome to comment and let me know.
Well, that aside, I would like to update anyone reading this on my progress. This week, I didn't do a whole lot of coding for the Supersonic engine, but I did quite a bit of reading. I have read about quite a few different game frameworks both specifically for OGRE, and unrelated to OGRE at all. Obviously I found those ones related to OGRE quite a bit more interesting and helpful, but I picked up some basic concepts (Singletons and threading) from other articles.
One of the most interesting articles I read was the Advanced OGRE Framework tutorial on OGRE's wiki. It is basically a code listing for a nice framework for OGRE applications, and appears to be quite useful to me. What little coding I have done this week was porting that framework to Python so I could use it myself. That framework includes with it a state manager, but I opted to write my code based off (not copying word for word) a different state manager also found on OGREs wiki. With that, I now have working input!
One thing that will inevitably be essential to the creation of a game engine is a Singleton. For that matter, it has definitely been a little challenging trying to figure out how to make a singleton in Python, because it's not a built in language feature. Luckily, this was made easy by another article I found: (link found on python-ogre wiki) Singleton Metaclass. Okay, I will admit I have not taken the time to look that over and figure it out (and considering it's simplicity, it seems like it might be pretty easy; don't forget: I only started programming with Python a few weeks ago). It sure looks promising though.
My plans from this point forward are still to get some kind of simple game in the works, featuring input, terrain, movement, animation, collision, game states (menu/pause menu) and a level manager. I have never ever used shaders before, and I barely even know what they are, but if I'm up to the challenge in the coming weeks I might even check out shaders and make some kind of weird metallic guy, or I could simply add a body of water; it would be cool to have a shiny rainbow tree though! For this week I'll simply work on animation.
I sure hope I can manage when it comes to the point of creating my own content. Anyone that would like to help me with that is welcome to comment and let me know.
Friday, January 21, 2011
Supersonic Game Engine Week 2!
Supersonic! That's just what I have temporarily titled my game engine. In other news: I broke everything - then fixed it, it's fine. Also, Calc-based Physics 1, Chemistry II and Calculus III, but that shouldn't be a problem. Also, in case you weren't aware, "45% Of Students Don't Learn Much In College" and that is quite a problem. Don't worry about me though, I'll be one of the students that learns a lot.
Anyways, as far as my game engine goes, I feel like it's been a good week. I haven't put in a ridiculous amount of hours into this project, but I did come up with a name, and I consider that to be a pretty significant amount of work. The name, by the way, if you didn't get it already, is Supersonic. One of the games I kind of wanted to model was the Sonic games of late, as they are platformers obviously. Another game I am looking at is Super Mario Galaxy (great game, haven't played the sequel yet but I hear it's even better).
Oh, don't worry, I did a lot more than just come up with a name. I also broke my python-ogre build by doing something.. not sure what. Well to cut the story short I reinstalled it and it's all good. And then Andy Miller (who apparently does most of the work on the OGRE Python wrapper) updated the SVN trunk with the latest version, 1.7.2 which probably supports Python 2.7, but I'll stick with 1.7.1 and Python 2.6 for now.
Anyways, on to the real details of my Supersonic 3D game engine project. Last week I vaguely talked about what my plans were for this project, now I will vaguely talk about what my plans are. For the most part, my number one goal for this semester is to get something that works and that I can show off. In order to do this, I am probably going to use a mix of different libraries. First and foremost, and most obviously will be OGRE, but along with that I'll be using OIS, and I would like to use CEGUI but that depends on whether or not I figure out how to make it work again (because I also broke it? or it just refuses to reinstall; I needed to change the install options so I was reinstalling it, and suddenly it absolutely refused to install claiming some version discrepancy of libtool, of which the script was written in 2.2.6b and supposedly I have 2.2.6... but in truth I actually have 2.2.6b so I don't know what's going on there). Anyways, I am planning on using some kind of physics engine to start with; a couple of possibilities are ODE and Bullet, both of which integrate well into OGRE which is nice.
In the near future I might be adding an AI library, and I'll have to do something about sound, but I haven't looked into possibilities for either of those. I certainly have the resources to test and therefore develop networking capabilities as well which I might also find some library to handle for me. As I get further into the development process, I would overall like the project to have it's own physics engine and AI library and such, but I wouldn't bet on that just yet. One thing that will definitely help in the long run is to make the project extensible by plugins, in case one of the libraries I use by default is discontinued.
Well as for what I'll be working on this week: I would like to make my own working InputManager (which relies on OIS for the moment), and I'd like to be able to create a scene with a controllable, animated character. For the most part I'll simply be using the resources that come with OGRE like the robot mesh and animation, and the terrain, etc. If anyone reading this would like to check out what I have, and help me make models and other art, that would be greatly appreciated. The art would mostly be used to demonstrate the capabilities, and for testing purposes, obviously. I can survive with the resources OGRE comes with by default though, so this isn't urgent.
Well, have a good week, and tune in next week for another exciting and epic tale of Supersonic Game Engine development!
Anyways, as far as my game engine goes, I feel like it's been a good week. I haven't put in a ridiculous amount of hours into this project, but I did come up with a name, and I consider that to be a pretty significant amount of work. The name, by the way, if you didn't get it already, is Supersonic. One of the games I kind of wanted to model was the Sonic games of late, as they are platformers obviously. Another game I am looking at is Super Mario Galaxy (great game, haven't played the sequel yet but I hear it's even better).
Oh, don't worry, I did a lot more than just come up with a name. I also broke my python-ogre build by doing something.. not sure what. Well to cut the story short I reinstalled it and it's all good. And then Andy Miller (who apparently does most of the work on the OGRE Python wrapper) updated the SVN trunk with the latest version, 1.7.2 which probably supports Python 2.7, but I'll stick with 1.7.1 and Python 2.6 for now.
Anyways, on to the real details of my Supersonic 3D game engine project. Last week I vaguely talked about what my plans were for this project, now I will vaguely talk about what my plans are. For the most part, my number one goal for this semester is to get something that works and that I can show off. In order to do this, I am probably going to use a mix of different libraries. First and foremost, and most obviously will be OGRE, but along with that I'll be using OIS, and I would like to use CEGUI but that depends on whether or not I figure out how to make it work again (because I also broke it? or it just refuses to reinstall; I needed to change the install options so I was reinstalling it, and suddenly it absolutely refused to install claiming some version discrepancy of libtool, of which the script was written in 2.2.6b and supposedly I have 2.2.6... but in truth I actually have 2.2.6b so I don't know what's going on there). Anyways, I am planning on using some kind of physics engine to start with; a couple of possibilities are ODE and Bullet, both of which integrate well into OGRE which is nice.
In the near future I might be adding an AI library, and I'll have to do something about sound, but I haven't looked into possibilities for either of those. I certainly have the resources to test and therefore develop networking capabilities as well which I might also find some library to handle for me. As I get further into the development process, I would overall like the project to have it's own physics engine and AI library and such, but I wouldn't bet on that just yet. One thing that will definitely help in the long run is to make the project extensible by plugins, in case one of the libraries I use by default is discontinued.
Well as for what I'll be working on this week: I would like to make my own working InputManager (which relies on OIS for the moment), and I'd like to be able to create a scene with a controllable, animated character. For the most part I'll simply be using the resources that come with OGRE like the robot mesh and animation, and the terrain, etc. If anyone reading this would like to check out what I have, and help me make models and other art, that would be greatly appreciated. The art would mostly be used to demonstrate the capabilities, and for testing purposes, obviously. I can survive with the resources OGRE comes with by default though, so this isn't urgent.
Well, have a good week, and tune in next week for another exciting and epic tale of Supersonic Game Engine development!
Friday, January 14, 2011
New game engine project
Well it's been a long time since I have blogged to be honest. I guess blogging isn't exactly my thing, but I'll continue. In the time since I have last blogged, I got a Droid X, I got a '97 Dodge Intrepid and I started a 3D platform game engine project for my Computer Programming class. Stay tuned for details on that game engine, and I'll also reveal my future plans for it
This post specifically is about that project. The class is going over Python, and considering my previous programming experience (years of casual reading book and articles, and once in a while playing with sample programs) Python was extremely easy for me to pick up. Something I've wanted to do for a long time is program a 3D game engine. After all who wouldn't want to do that? Well on second thought, I guess the people interested in making their own games would rather use an engine which has already been made, and matured.
Anyways, the 3D platform game engine has yet to be named as you may have noted. Right now I am building it in Python using the python-ogre library, which is simply a Python wrapper for OGRE3D.
My plans for the game engine this semester simply involve getting something that works. In my mind that entails getting the following things up and running: terrain, movement, animation and collision first, then states and a menu, and level importing. Basically, by the end of the semester I'd like to be able to import a level and all associated objects and create a 3D scene with a player (shown in third person), a couple of enemies, static entities and a couple of other dynamic entities. I would like to be able to do some very simple scripting (and with Python, this will be easy!) for the enemies, and possibly triggered events.
After the semester is over, the number of options I have to do with the project could be represented by a HUGE tree. I think the best thing to do would be to port it to C++, set up a project on source forge, make a website and then possibly advertise it a little bit to recruit a couple of other developers to help me. Obviously this is going to be an open-source project and I will primarily be developing from Ubuntu Linux. I'll have more details on future plans as things progress; I wouldn't want to build up too many dreams and then lose focus in the project. This really is a big thing for me and I hope later to make it a big thing for the world! After all, it seems that Linux and the open-source community lacks a little in the gaming market.
This post specifically is about that project. The class is going over Python, and considering my previous programming experience (years of casual reading book and articles, and once in a while playing with sample programs) Python was extremely easy for me to pick up. Something I've wanted to do for a long time is program a 3D game engine. After all who wouldn't want to do that? Well on second thought, I guess the people interested in making their own games would rather use an engine which has already been made, and matured.
Anyways, the 3D platform game engine has yet to be named as you may have noted. Right now I am building it in Python using the python-ogre library, which is simply a Python wrapper for OGRE3D.
My plans for the game engine this semester simply involve getting something that works. In my mind that entails getting the following things up and running: terrain, movement, animation and collision first, then states and a menu, and level importing. Basically, by the end of the semester I'd like to be able to import a level and all associated objects and create a 3D scene with a player (shown in third person), a couple of enemies, static entities and a couple of other dynamic entities. I would like to be able to do some very simple scripting (and with Python, this will be easy!) for the enemies, and possibly triggered events.
After the semester is over, the number of options I have to do with the project could be represented by a HUGE tree. I think the best thing to do would be to port it to C++, set up a project on source forge, make a website and then possibly advertise it a little bit to recruit a couple of other developers to help me. Obviously this is going to be an open-source project and I will primarily be developing from Ubuntu Linux. I'll have more details on future plans as things progress; I wouldn't want to build up too many dreams and then lose focus in the project. This really is a big thing for me and I hope later to make it a big thing for the world! After all, it seems that Linux and the open-source community lacks a little in the gaming market.
Subscribe to:
Posts (Atom)
